**From:** Peter F. Patel-Schneider (*[email protected]*)

**Date:** 12/04/01

**Next message:**Deborah McGuinness: "Re: (DQL) Expressiveness of Query Patterns"**Previous message:**Joseph Coffman: "Fwd: member submission from ["Jonathan Borden" <[email protected]>]"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ] [ attachment ]**Mail actions:**[ respond to this message ] [ mail a new topic ]

As it is sort of on today's agenda, here is the current status of my effort to reconcile DAML+OIL with the new RDF model theory. Note: This is only a draft. It is undergoing continuous revisions as I detect (and, hopefully, fix) problems. I believe that there are missing semantic conditions, particularly in the RDFS conditions. Nevertheless, it does provide, I think, a coherent and reasonable approach to layering DAML+OIL on top of the new definition of RDF. peter Bringing the new RDF Model Theory to DAML+OIL Peter F. Patel-Schneider Bell Labs Research (4 December 2001) [This is a draft. There are probably minor pieces missing.] This is a new way of looking at DAML+OIL that is more compatible with the new RDF model theory. I have tried to identify the tricky points below. The basic idea is to stay with the RDF approach of having the syntax of semantically-meaningful constructs like subclass also show up as relationships in interpretations. This is extended to what I think is a reasonable point that does not exhibit any paradoxes. However, the class-forming operators of DAML+OIL do not get this treatment, as doing so would result in paradoxes and an ill-formed model theory. The RDF constructs like subclass are also given a more-powerful meaning. This meaning is upward compatible with the RDF meaning but is more in keeping with DAML+OIL. Knowledge Bases: A DAML+OIL knowledge base is a collection of statements. Some of these statements are RDF triples, some are not. [I will leave the syntax of the non-RDF constructs vague for now.] Datatypes: A datatyping scheme is a collection of datatypes, DT. A datatype d in DT is a triple <Ld,Vd,LVd> where Ld is its lexical space Vd is its value space LVd : Ld -> Vd is its lexical-to-value mapping Given a datatyping scheme, let L = union over d in DT of Ld, lexical values V = union over d in DT of Vd, data values LV = union over d in DT of LVd [This way works best if there is a collection of primitive datatypes, like integer, and the range-restriction of LV to the value spaces of each of these datatypes is functional. The presence of datatypes where this is not true, like XML Schema union datatypes, does not cause severe problems, as long as one realizes that the DAML+OIL type theory only restricts the result of the lexical-to-value map, not the actual map. Thus stating that the range of a property is integer union string does not turn sequences of digit characters into integers.] Lexical Issues: N is a collection of names (URIs). E is a collection of identifiers (blank node ids), disjoint from N. K is a collection of literal occurences, of the form <l,d> where l is in L, d is in DT l:n where l is in L, n is an integer (or some other tag) Interpretations: A DAML+OIL interpretation, I, over a datatyping scheme DT is a generalized simple RDFS interpretation, consisting of R, nonempty the domain of resources P <= R, nonempty properties C <= R, nonempty classes EXT : P -> 2^(Rx(RuV)) property extensions CEXT : C -> 2^(RuV) class extensions M : N -> R mapping from names to denotation an extended DAML+OIL interpretation, I', is an interpretation with the following additional component A : E -> R mapping from blank nodes to denotation I' is said to extend I if they agree on R, P, C, EXT, CEXT, and M. Both have the following conditions. >From RDF: M(rdf:type) in P for x in R x in CEXT(y) iff <x,y> in EXT(M(rdf:type)) [rdf:type only lines up with CEXT on resources, not data values >From RDFS: [Note: I may be missing some semantic relationships in this section.] CEXT(M(rdfs:Resource)) = R CEXT(M(rdf:Property)) = P CEXT(M(rdfs:Class)) = C CEXT(M(rdfs:Literal)) = V M(rdfs:Resource), M(rdf:Property) in C\DT M(rdfs:Class), M(rdfs:Literal) in C\DT < M(rdfs:Class), M(rdfs:Resource) > in EXT(M(rdfs:subClassOf)) < M(rdfs:Property), M(rdfs:Resource) > in EXT(M(rdfs:subClassOf)) M(rdfs:subClassOf), M(rdfs:subPropertyOf) in P M(rdfs:domain), M(rdfs:range) in P for x,y in C\DT <x,y> in EXT(M(rdfs:subClassOf)) iff CEXT(x) <= CEXT(y) [rdf:subClassOf only lines up with CEXT on non-datatypes] <r,s> in EXT(IS(rdfs:subPropertyOf)) iff EXT(r) <= EXT(s) if <x,y> in EXT(p) and <p,c> in EXT(M(rdfs:domain)) then x in CEXT(c) if <x,y> in EXT(p) and <p,c> in EXT(M(rdfs:range)) then y in CEXT(c) < M(rdf:type), M(rdfs:Class) > in EXT(M(rdfs:range)) < M(rdfs:subClassOf), M(rdfs:Class) > in EXT(M(rdfs:domain)) < M(rdfs:subClassOf), M(rdfs:Class) > in EXT(M(rdfs:range)) < M(rdfs:subPropertyOf), M(rdfs:Property) > in EXT(M(rdfs:domain)) < M(rdfs:subPropertyOf), M(rdfs:Property) > in EXT(M(rdfs:range)) < M(rdfs:domain), M(rdfs:Property) > in EXT(M(rdfs:domain)) < M(rdfs:domain), M(rdfs:Class) > in EXT(M(rdfs:range)) < M(rdfs:range), M(rdfs:Property) > in EXT(M(rdfs:domain)) < M(rdfs:range), M(rdfs:Class) > in EXT(M(rdfs:range)) < M(rdfs:label), M(rdfs:Literal) > in EXT(M(rdfs:range)) < M(rdfs:comment), M(rdfs:Literal) > in EXT(M(rdfs:range)) M(rdfs:seeAlso), M(rdfs:isDefinedBy) in P < M(rdfs:isDefinedBy), M(rdfs:seeAlso) > in EXT(M(rdfs:subPropertyOf)) < M(rdf:seeAlso), M(rdfs:Resource) > in EXT(M(rdfs:range)) For datatypes: DT <= C M(daml:Datatype) in C\DT CEXT(M(daml:Datatype)) = DT for d in DT CEXT(d) = Vd For DAML+OIL: M(daml:Class) in C\DT M(daml:ObjectProperty), M(daml:DatatypeProperty) in C\DT M(daml:UniqueProperty), M(daml:UnambiguousProperty) in C\DT M(daml:TransitiveProperty) in C\DT <M(daml:Class), M(rdfs:Class)> in EXT(M(rdfs:subClassOf) <M(daml:ObjectProperty), M(rdf:Property)> in EXT(M(rdfs:subClassOf) <M(daml:DatatypeProperty), M(rdf:Property)> in EXT(M(rdfs:subClassOf) <M(daml:UniqueProperty), M(rdf:Property)> in EXT(M(rdfs:subClassOf) <M(daml:UnambiguousProperty),M(daml:ObjectProperty)> in EXT(M(rdfs:subClassOf) <M(daml:TransitiveProperty), M(daml:ObjectProperty)> in EXT(M(rdfs:subClassOf) x in CEXT(M(daml:Class)) iff CEXT(x) <= R x in CEXT(M(daml:ObjectProperty)) iff x in P and EXT(x) <= R x R x in CEXT(M(daml:DatatypeProperty)) iff x in P and EXT(x) <= R x V x in CEXT(M(daml:UniqueProperty)) iff x in P and EXT(x) is functional x in CEXT(M(daml:UnambiguousProperty)) iff x in CEXT(M(daml:ObjectProperty)) and converse EXT(x) is functional x in CEXT(M(daml:TransitiveProperty)) iff x in CEXT(M(daml:ObjectProperty)) and EXT(x) o EXT(x) <= EXT(x) M(daml:sameClassAs), M(daml:disjointWith) in P M(daml:samePropertyAs) in P M(daml:sameIndividualAs), M(daml:differentIndividualFrom) in P <M(daml:sameClassAs), M(rdfs:subClassOf)> in EXT(M(rdfs:subPropertyOf) <M(daml:samePropertyAs), M(rdfs:subPropertyOf)> in EXT(M(rdfs:subPropertyOf) <M(daml:sameClassAs),M(rdfs:Class)> in EXT(M(rdfs:domain)) <M(daml:sameClassAs),M(rdfs:Class)> in EXT(M(rdfs:range)) <M(daml:disjointWith),M(rdfs:Class)> in EXT(M(rdfs:domain)) <M(daml:disjointWith),M(rdfs:Class)> in EXT(M(rdfs:range)) <M(daml:samePropertyAs),M(rdf:Property)> in EXT(M(rdfs:domain)) <M(daml:samePropertyAs),M(rdf:Property)> in EXT(M(rdfs:range)) <M(daml:sameIndividualAs),M(rdfs:Resource)> in EXT(M(rdfs:domain)) <M(daml:sameIndividualAs),M(rdfs:Resource)> in EXT(M(rdfs:range)) <M(daml:differentIndividualFrom),M(rdfs:Resource)> in EXT(M(rdfs:domain)) <M(daml:differentIndividualFrom),M(rdfs:Resource)> in EXT(M(rdfs:range)) <x,y> in EXT(M(rdfs:subClassOf)) iff x,y in C\DT and CEXT(x) <= CEXT(y) <x,y> in EXT(M(daml:sameClassAs)) iff x,y in C\DT and CEXT(x) = CEXT(y) <x,y> in EXT(M(daml:disjointWith)) iff x,y in C\DT and CEXT(x)^CEXT(y) = {} <x,y> in EXT(M(rdfs:subPropertyOf)) iff x,y in P and EXT(x) <= EXT(y) <x,y> in EXT(M(daml:samePropertyAs)) iff x,y in P and EXT(x) = EXT(y) <x,y> in EXT(M(daml:sameIndividualAs)) iff x,y in R and x=y <x,y> in EXT(M(daml:differentIndividualFrom)) iff x,y in R and x/=y Satisfaction: An extended interpretation DAML+OIL-satisfies statements as follows. Note that some statements match multiple conditions, e.g., S rdfs:subClassOf O. Statement Condition S P O [an RDF triple] < IO(S), IO(O) > in EXT(M(P)) [as in RDF MT] S rdf:type D IO(S) in ID(D) D1 rdfs:subClassOf D2 ID(D1) <= ID(D2) D1 daml:sameClassAs D2 ID(D1) = ID(D2) D1 daml:disjointWith D2 ID(D1) disjoint from ID(D2) P1 rdfs:subPropertyOf P2 EXT(M(P1)) <= EXT(M(P2)) P1 daml:samePropertyAs P2 EXT(M(P1)) = EXT(M(P2)) P rdfs:domain D EXT(M(P)) <= ID(Q) x R P rdfs:range D EXT(M(P)) <= R x ID(Q) where {S P O} is an RDF triple P, P1, P2 are names S, S1, S2 are names or blank node identifiers D, D1, D2 are descriptions (see below) Q, Q1, Q2 are roles (see below) O is a name or blank node identifier or literal occurence and IO : O -> R v V as follows Construction Mapping S a name M(S) b a blank node A(b) <l,d> a typed literal occurence LVd(l) l:n an untyped literal occurence in LV(l) [untyped literal occurences are underspecified] and ID : D -> 2^R as follows [ID does not allow non-resources in extensions] Construction Extension S CEXT(M(S)) ^ R Thing R Nothing { } unionOf D1...Dn ID(D1) v ... v ID(Dn) intersectionOf D1...Dn ID(D1) ^ ... ^ ID(Dn) complementOf D R\ID(D) oneOf S1 ... Sn { M(S1), ..., M(Sn) } toClass Q D { x : <x,y> in IR(Q) implies y in IC(D) } hasValue Q O { x : <x,M(O)> in IR(Q) } hasClass Q D { x : exists y <x,y> in IR(Q) and y in IC(D) } minCardinality n Q { x : >=n y <x,y> in IR(Q) } maxCardinality n Q { x : <=n y <x,y> in IR(Q) } cardinality n Q { x : exactly n <x,y> in IR(Q) } minCardinalityQ n Q D { x : >=n y <x,y> in IR(Q) and y in IC(D) } maxCardinalityQ n Q C { x : <=n y <x,y> in IR(Q) and y in IC(D) } cardinalityQ n Q C { x : exactly n <x,y> in IR(Q) and y in IC(D) } and IC : D -> 2^(RuV) as follows Construction Extension S CEXT(M(S)) D (except S) ID(D) and IR : Q -> 2^(RxR) as follows Construction Extension P EXT(M(P)) if M(P) in CEXT(daml:ObjectProperty) EXT(M(P)) if M(P) in CEXT(daml:DatatypeProperty) [unspecified otherwise] inverseOf R converse of IR(R) if EXT(R) <= RxR [unspecified otherwise] Models and entailment: An extended interpretation DAML+OIL-satisfies a knowledge base if it DAML+OIL-satisfies every statement in the knowledge base. An interpretation is a model for a DAML+OIL knowledge base if there is some extension of the interpretation that satisfies the knowledge base. A DAML+OIL knowledge base, KB1, entails another, KB2, if all models of KB1 are also models of KB2. Status of all RDF, RDFS, and ``old'' DAML-OIL constructs not handled above: Surface syntax - does not show up at this level xmlns:* rdf:aboutEach rdf:aboutEachPrefix rdf:li rdf:parseType rdf:RDF rdf:Description rdf:ID rdf:about rdf:resource Ontology versionInfo imports Obsolete surface syntax - not needed rdf:parseType of daml:collection daml:List daml:nil daml:first daml:rest daml:item Constructs with no special treatment needed rdfs:label rdfs:comment rdf:value rdfs:seeAlso rdfs:isDefinedBy Unneeded description syntax daml:Restriction daml:onProperty daml:hasClassQ Not handled (yet) daml:disjointUnionOf Problematic Constructs RDF reification - rdf:subject, rdf:predicate, rdf:object, rdf:Statement - rdf:bagID - what does it mean? RDF containers - rdfs:Container, rdf:Seq, rdf:Bag, rdf:Alt, rdf:_n - what do they mean? daml:equivalentTo - what does it mean?

**Next message:**Deborah McGuinness: "Re: (DQL) Expressiveness of Query Patterns"**Previous message:**Joseph Coffman: "Fwd: member submission from ["Jonathan Borden" <[email protected]>]"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ] [ attachment ]**Mail actions:**[ respond to this message ] [ mail a new topic ]

*
This archive was generated by hypermail 2.1.4
: 04/02/02 EST
*