DRAFT $Revision: 1.8 $ of $Date: 2002/02/13 20:52:52 $
by Dan Connolly, @@Ian Horrocks, Mike Dean
following from NJ ftf
update in progress: use requirements draft of 7Feb
For example, see the way the SRI topic ontology refers to terms from their organization, project, researcher, publication, and contactinfo ontologies:
<daml:Ontology rdf:about=""> [...] <daml:imports rdf:resource="http://www.ai.sri.com/daml/ontologies/sri-basic/1-0/Organization.daml"/> <daml:imports rdf:resource="http://www.ai.sri.com/daml/ontologies/sri-basic/1-0/Project.daml"/> <daml:imports rdf:resource="http://www.ai.sri.com/daml/ontologies/sri-basic/1-0/Researcher.daml"/> <daml:imports rdf:resource="http://www.ai.sri.com/daml/ontologies/sri-basic/1-0/Publication.daml"/> <daml:imports rdf:resource="http://www.ai.sri.com/daml/ontologies/sri-basic/1-0/ContactInfo.daml"/> </daml:Ontology>
Note that we're
presumingontologyjust means a document that uses
ontology-building vocabulary, and if http://example/vocab is a
URI of an ontology and http://example/vocab#term is mentioned in
that ontology, then http://example/vocab#term is from
http://example/vocab.
There are two mechanisms:
DAML+OIL inherits from RDF 1.0 the ability to refer to/share terms from other documents, much like HTML <a href> and <a name>.
which explicitly says "commitment to this document entials commitment to that document".
Actually, it's not 100% clear what daml:imports says. The DAML+OIL specs don't provide a formal specification for it; its semantics seem connected to the state of the web, i.e. protocols, time, and that sort of thing, which are outside the realm of normal DAML+OIL reasoning.
The usual DAML+OIL practice is, for example:
<daml:Ontology rdf:about=""> <daml:versionInfo>$Id: reqdo.html,v 1.8 2002/02/13 20:52:52 connolly Exp $</daml:versionInfo> <rdfs:comment>SRI's ontology for topics </rdfs:comment>
There are two mechanisms here:
This meets the requirements of a certain sort of book-keeping use cases, but it's little more than glorified comments. What were the use cases behind this requirement again?
DAML+OIL ontologies may, and often do, use the rdfs:label
property to supply a lexical representation of each term; e.g. from a Chimaera-JTP
testing ontology:
<QueryItem rdf:ID="Correct-Cardinality-Query"> <rdfs:label> Correct-Cardinality-Query </rdfs:label>
RDF is intended to provide internationalization of labels, but it's not clear that it does. The spec says
The xml:lang attribute may be used as defined by [XML] to associate a language with the property value.
but then it goes on to say
There is no specific data model representation for xml:lang
The RDF Core WG is tracking this issue:
DAML+OIL leverages the existing naming context of the web, i.e. URIs for its terms. This is an extremely widely deployed convention for allocating names and associating documents with them.
Meanwhile, the simultaneous use of URIs as logical names and as keys in network protocols, and the integration of URIs with XML raises issues such as:
DAML+OIL doesn't make the unique-names assumption for URIs/logical names. On the contrary, it has explicit vocabulary for stating that two names denote the same thing (sameIndividualAs, equivalentTo).
It's possible to use cardinality constraints with string-valued properties to express things like "if x's colorName is different from y's colorName, then x != y". For details, see:
But it's not clear that (a) this is sufficiently straightforward to be acceptable to ontology designers and content authors, nor (b) that this approach addresses the computational feasability issues that usually motivate the unique-names assumption. Also, Ian suggests there may be paradoxes in this sort of solution.
DAML+OIL meets this requirement (or fails to meet it) as much as any other XML-based data format.
There some cases where two different sequences of unicode characters, say one using pre-composed form (just one c-cedilla character) and another using decomposed form (a c character followed by a cedilla accent character) that look the same and are expected, by most users, to compare equal; e.g. to match in queries. There seem to be two ways to meet user expectations:
The W3C I18N has decided on that early uniform normalization; their specification isn't a W3C recommendation yet, but consensus is building, and it should become one any time now.
DAML+OIL meets this requirement (or fails to meet it) as much as any other XML-based data format.
Internationalization is one of the core features of XML. With regard to character sets, this means:
DAML+OIL has a few rudimentary features relevant to ontology management:
That doesn't seem to meet the user community's requirement for ontology management, but perhaps what is lacking is documentation and methodological advice, rather than language features.
@@needs elaboration
@@I don't remember what this means well enough to evaluate DAML+OIL against it; I'll try again when we have a draft requirements document.
DAML+OIL can express, e.g. "partNumber is a myOraclMapping:Property".
It also has TransitiveProperty, and can express, indirectly, SymmetricProperty.
But I understand there's some problem with ReflexiveProperty.
I'm not sure. @@Ian? help?
yes/sorta. sameIndividualAs, sameClassAs, subClassOf, subPropertyOf
sorta; daml:imports
not explicitly.
But Ian mentioned something about a "keys for free in description logics" paper that suggested it can be layered on top "for free".
yes/sorta (daml:imports)
no.
no.
no: DAML is all one layer.
yes: DAML is layered in RDFS (which is layered on RDF, which is layered on XML and URIs)
no (no chaining of properties)
yes?(Ian, care to elaborate?)
no
???
no. no explicit support, anyway.
no
no?
no explicit support.
no obvious problems with straightforward application of XML Signature, meanwhile.
no.
no
no
no?
no. (we considered something ala rdfs:label, but didn't decide to do it)