Re: FOAF DL

On Fri, 2010-07-16 at 16:17 +0100, Antoine Zimmermann wrote: 
> Beware, technical stuff follows.
> 
> 
> 
> Le 16/07/2010 13:07, Dave Reynolds a écrit :
> > Looks interesting.
> >
> > In the description you say "(1) foaf:mbox_sha1sum, foaf:jabberID,
> > foaf:aimChatID, foaf:icqChatID, foaf:yahooChatID and foaf:msnChatID are
> > not owl:InverseFunctionalProperties anymore; instead, they are defined
> > as owl:Keys for foaf:Agents, which is practically the same"
> >
> > I agree that making them owl:Keys is the only option for DL but the
> > comment "practically the same" is maybe overstating it.
> >
> > My understanding was that the semantics of Keys [1] only applies to
> > named individuals and so isn't effective on anonymous individuals (which
> > is a common use case in FOAF). Is that correct?
> 
> Yes, you are correct.
> 
> Here, I made a simplifying short cut but saying "practically the same". 
> In most cases, a blank node can be simply considered as a named 
> individual, using the blank node ID (regardless of whether it is 
> specified in the serialisation or internally represented) as a "name" 
> for the individual.
> In this case, the un-named individual are only those that exists because 
> of inferences but which have no identifier at all (for instance, when 
> using the OWL construct "owl:someValueFrom".
> 
> Such shortcuts are practically used in reasoners to deduce things about 
> blank nodes in the same way they deduce things about URIs.
> 
> 
> Using this approach on the following data:
> 
> 
> foaf:yahooChatID a owl:DatatypeProperty ;
>                   rdfs:domain foaf:Agent .
> foaf:Agent owl:hasKey ( foaf:yahooChatID ).
> _:bnode1 foaf:yahooChatID "xyz" .
> _:bnode2 foaf:yahooChatID "xyz" .
> 
> 
> one can infer:
> 
> 
> _:bnode1 owl:sameAs _:bnode2 .
> 
> 
> When the serialisation does not specify a name for a blank node, their 
> is still an internal name somewhere.  For instance:
> 
> 
> [ a :Person ] foaf:yahooChatID "xyz" ;
>     foaf:firstName "John" .
> [ a :Person ] foaf:yahooChatID "xyz" ;
>     foaf:lastName "Doe" .
> 
> allows one to infer that there is one person with first name "John" and 
> last name "Doe" (but its local identifier is only known to the reasoner).
> 
> An example where the inference would not hold is as follows:
> 
> :chatID a owl:DatatypeProperty ;
>          rdfs:domain :Agent .
> :Agent owl:hasKey ( :chatID ).
> :hasFather a owl:ObjectProperty, owl:FunctionalProperty .
> :john :chatId "xyz" .
> :bob a [ owl:Restriction ;
>           owl:onProperty :hasFather ;
>           owl:allValuesFrom [ a owl:Restriction;
>                               owl:onProperty :chatId;
>                               owl:hasValue "xyz" ]
>         ] .
> 
> from this, we cannot conclude that John is the father of Bob, although 
> Bob has a father (un-named) whose :chatId is exactly the same as John.
> If :chatId was inverse functional, we could conclude it. However, I said 
> "practically the same" because this case is unlikely to occur in practice.
> 
> 
> Hope it's clear enough. For the specs for keys, see [1,2,3].

Yes that's clear and reasonable. 

I had looked at those parts of the specs but the phrasing in [1] seemed
to rule out blank nodes since the RDF semantics [3] specifically states
that blank nodes are existentially quantified variables:

"are treated as simply indicating the existence of a thing, without
using, or saying anything about, the name of that thing. (This is not
the same as assuming that the blank node indicates an 'unknown' URI
reference; for example, it does not assume that there is any URI
reference which refers to the thing."

However, you are basically saying that the Skolemization lemma applies
here, which makes sense.

Thanks,
Dave

[3] http://www.w3.org/TR/rdf-mt/#unlabel


> [1] OWL 2 Web Ontology Language - Structural Specification and 
> Functional-Style Syntax, Sect.9.5 Keys. 
> http://www.w3.org/TR/owl2-syntax/#Keys
> [2] OWL 2 Web Ontology Language - New Features and Rationale, Sect.2.2.6 
> F9: Keys. http://www.w3.org/TR/owl2-new-features/#F9:_Keys
> [3] OWL 2 Web Ontology Language - Direct Semantics, Sect.2.3.5 Keys. 
> http://www.w3.org/TR/owl2-semantics/#Keys
> 
> 
> Regards,
> >
> > Dave
> >
> > [1] http://www.w3.org/TR/owl2-direct-semantics/#Keys
> >
> > On Fri, 2010-07-16 at 12:16 +0100, Antoine Zimmermann wrote:
> >> Dear all,
> >>
> >>
> >> I know that the compatibility of FOAF with OWL DL has been discussed a
> >> lot in the past (and still sometimes surfaces again).  However, I'm
> >> wondering, would it be reasonable to provide a DL version of FOAF in
> >> complement of the official FOAF ontology?
> >> More generally, wouldn't it be reasonable to provide alternative
> >> versions of an ontology?  Think of XHTML: there are three different XML
> >> Schemas for XHTML [1].  One could imagine alternative versions like FOAF
> >> (Full), FOAF-DL, FOAF-lite...
> >>
> >> Anyway, I did it: I've made a FOAF-DL ontology which modifies the FOAF
> >> ontology such that (1) it is in OWL 2 DL and (2) it maximally preserves
> >> inferences of the original FOAF ontology [2].
> >>
> >> Interestingly, FOAF-DL is an OWL 2 RL ontology (in a nutshell, OWL 2 RL
> >> is a subset of OWL 2 DL with low computational complexity and that is
> >> compatible with rule-based inference engine).
> >>
> >> You may notice that there are strange annotation properties for this
> >> ontology:
> >>
> >> <owl:Ontology rdf:about="http://purl.org/az/foaf#">
> >>     ...
> >>     <yoda:preferredVersion rdf:resource="http://xmlns.com/foaf/0.1/"/>
> >>     ...
> >> </owl:Ontology>
> >>
> >> The Yoda vocabulary [3] is used to relate alternative versions of an
> >> ontology. Here, it is said that there is a preferred version, which is
> >> the official FOAF ontology.
> >>
> >> Critiques to any of the previous comments are welcome.
> >>
> >>
> >> [1] http://www.w3.org/TR/xhtml1-schema/#schemas
> >> [2] The FOAF-DL ontology. http://purl.org/az/foaf
> >> [3] Yoda: A Vocabulary for Linking Alternative Specifications of a
> >> Vocabulary. http://purl.org/NET/yoda
> >>
> >>
> >> Regards,
> >
> >
> 
>

Received on Friday, 16 July 2010 16:13:39 UTC