First Q was, is the agenda public? Will it be revisable? Skip basics Will we have a charter at the end of the day? Published publicly SHOE:began in ~1995, first paper in 96 Jeff Heflin joined in 96 Key thing is ontology, need to be sharable and extensible, open on the web, Category taxonomies are important because people use them a lot Need more than binary relations Need to be able synonyms, aliases Wanted Horn clause like inference, if-thens are easy, pred-logic isn't Constants are short-hand refs, short names Taxonomies can be extended, but middle nodes can't be modified later The taxonomy is a graph, not a tree, a rule could work around merge things, Have used PARKA as hierarchical storage Ontologies provide context for scope of applicable rules Rule prof(x) -> hated-person(x), find me all X (hated, professor) [SHOE has no negation] how often does a web-search actually return nothing? SHOE gives lists of answers, but won't say "there is no such thing" Optimizations can be derived from ontologies Can define custom types, is probably application-dependent, kinda like the constants Want to avoid inconsistency, thus no negation, cardinality, disjoint classes, simplifies combining Allow for change, so version #s, urls, backward compatible to use older info Ontologies were to be commonly stored, URLs are not reliable, Original ontologies became more generalized fairly quickly but meanings can change in the process it is possible to have a new ontology with a completely different base, but that won't interoperate with others should DAML "come with" a basic ontology? What would be in it? "where" would it be? Is it anything beyond basic abstract concepts? DanC: There's a trust issue about the basic ontology--is it neutral enough? Is there enough there so That folks aren't building from basic atoms all the time Rules: basic relationships (membership, inheritance flavors) Map between ontologies (differences of arg-types, more than just renaming) Macros would prove interesting as rule-rewriters, for re-use DanC got on his soapbox about recording all comm traffic, any conversations. There's this "rules subgroup" that has met without producing any minutes. Dan was unhappy Issues: ID of individuals is hard, using URLs isn't safe enough, URL of a specific content may Change over time Metadata vs content: does the URL name the page or a concept DanC: working from HTML to RDF isn't hard. How does he automatethis? Hindsight: shorthand for binary relations Need inverse relations (OIL apparently has them) Need better name handling Need to specify equivalence of instances Label things as deprecated Support for composite types Persistence, dynamic lifetime/expiration Arithmetic fns, need units conversions String manip User-defined fns (java? Scripting?) Contraints, requires conflict res Belief systems: need rules of what to believe, or logic primitives ORA: RDF design rationale Showed timeline Model needed to stay simple, but not TOO simple The spec is not the territory, it needs a more philosophical doc. Syntax: What is the concrete syntax, parens vs xml Namespaces were deemed necessary, so they were forced through W3C Need some power tools, DanC says "they'll happen". What about before then? Based on other stds, XML, URI, http… Takes care of many details DanC: web pp can have designated lifetimes for caching/refresh purposes. Class is prototype, not a classification Metaclasses are hard Domain and range were hard explanations Interesting diagram about class relationships Some comm has been simply ad nominem DanC: Microsoft is a hard problem, historically against RDF Too much of this is marketing driven. What should DAML be layered on? Hendler thinks DAML should layer on RDF rather than XML. DanC: W3C mgmt process details. Charter issues got discussed, Committee was started with personnel from the DARPA DAML program and the EU program. Committee will in the future add membership based on a majority vote of the WG? Or committee will add members based on an open call to rdf-logic? Much discussion occurred about who is/can-be members. W3C has somewhat different rules about what a charter has to include that won't work with JimH's goals about getting things done and adopted. It was a tough discussion: how to achieve some semblance of fairness regarding new members without losing control, achieve W3C buy-in/approval, and ending up with something other than DAML-ont. JimH explained what he is now proposing as the org-structure. The existing lang WG releases the DAML-O spec, disbands, and reforms around the logic language. DAML-O becomes RDF- O, and the Logic Lang Interest Group. Dan and Jim wrote a basic statement about the org outcomes. One new goal is to have the new charter ready at end of Jan 2001. IAN: OIL Frame-like syntax, logic-syntax is scary Semantics from a description logic, Layered on RDF Key feat is reasoning support Design support tool Large ontos Multiple authors Consistency checking More important design-time as opposed to use-time Defined classes, many slot contraints possible, Concrete date types like numbers/strings, Axioms like negation Hope to make a CORBA-accessible server (to do ?) Infrastructure growing, reasoner and edit tools, more needed EU consortium to work on onto research (ontoweb thematic network) Related group for infrastructure research (wonderweb) Ian showed the existing tools, an OIL ontology editor. You can build the full language via the UI. The OMAR/Diane tools do this same thing, for an entirely different purpose. Reasoner will find inconsistencies, but does allow the inconsistencies to remain. Codes are available under GPL. Another one is an ER-diagram tool, interfaces to the same reasoner engine. Frank: Presentation syntax Why: human<->human communicatoin Easy to work with For use when power tools not around. Constraints: unambig, easy to parse Agree on need, examples Define grammar, generate parser, build RDF translators Example delta: rdf/xml is huge, the compressed syntax is tiny, but is it easier to read? DAY 2 Presentation syntax came up again, there are two competing proposals, we need a bake-off as to which one can correctly read/write/read a couple of large ontologies without destroying them. Concrete domains: must have the basic datatypes (int, string, etc) Dan showed the basic set. Dan asked the Q of how to do you determine equality of two seemingly simple pairs of numbers, Ian gave the OIL equation, it isn't simple--who is going to create this? Can DAML express something like this? What is the right logic for it? We hit the problem of there being some language-specific keywords, which cannot be redefined. I.e., you can't redefine TYPE and CLASS. Dan argues that isn't the only way. Dan argues that TYPE is just a property/relationship, CLASS likewise, and their meaning is arbitrary and mutable. Is the semantics something that goes with the language, or with the tool? Frank argues that it is thetool.. Dan wants theorem proving as basic semantics. Variances in semantics can lead to incomplete reasoning, invalid answers. Primitive types will be treated as black boxes. The behavior is definable, but you can't see the actual implementation. Around lunch were discussions regarding finer-grain details of what some daml keywords mean. Discussion occurred about enhancements to the DAML.org web-pp, official doc released, version #s, updates to other docs in daml.org repository Presentation syntax: put it on the web-page. It is still work in progress… "point 8" -- Ian: renaming vs explicit namespaces. Renaming is in, with a note saying this may change. Next meeting?