W3C home > Mailing lists > Public > public-owl-dev@w3.org > October to December 2009

Re: Questions on RDF mapping of OWL 2 data ranges

From: Pat Hayes <phayes@ihmc.us>
Date: Tue, 10 Nov 2009 10:44:13 -0600
Cc: Holger Knublauch <holger@topquadrant.com>, public-owl-dev@w3.org, Michael Schneider <schneid@fzi.de>
Message-Id: <3604F0F2-020E-4DB1-A467-22D3B1B3AA29@ihmc.us>
To: Alan Ruttenberg <alanruttenberg@gmail.com>

On Nov 9, 2009, at 7:33 PM, Alan Ruttenberg wrote:

> On 11/9/09, Pat Hayes <phayes@ihmc.us> wrote:
>>
>> On Nov 9, 2009, at 5:23 PM, Alan Ruttenberg wrote:
>>
>>> On Mon, Nov 9, 2009 at 4:06 PM, Holger Knublauch <holger@topquadrant.com
>>>> wrote:
>>>> Dear group,
>>>>
>>>> I am unsure about the right (and best) way of mapping user-defined
>>>> OWL 2
>>>> datatypes to RDF graphs. I have been skimming through the OWL specs
>>>> but all
>>>> examples I saw were of the following format (see
>>>> http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Datatype_Definitions)
>>>>
>>>> :
>>>>
>>>>       a:SSN rdf:type rdfs:Datatype .
>>>>       a:SSN owl:equivalentClass _:x .
>>>>       _:x rdf:type rdfs:Datatype .
>>>>       _:x owl:onDatatype xsd:string .
>>>>       _:x owl:withRestrictions ( _:y ) .
>>>>       _:y xsd:pattern "[0-9]{3}-[0-9]{2}-[0-9]{4}" .
>>>>
>>>> This means that a datatype is an instance of rdfs:Datatype that has
>>>> an
>>>> owl:equivalentClass of another (anonymous) datatype which then
>>>> points to the
>>>> fact restrictions as an rdf:List.
>>>>
>>>> 1) Would it also be allowed to use rdfs:subClassOf instead of
>>>> owl:equivalentClass?
>>>
>>> No. The mappings are defined precisely in
>>> http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/
>>
>> But wait. It is certainly *correct* to use subClassOf instead of
>> EquivalentClass, since the latter entails the former. It might not
>> convey the full intention of the original OWL, of course, but that
>> does not make it into an error.
>
> I read his question as a question of whether the cited
> DatatypeDefinition could be encoded as he proposes. It can not.

Ah, I see. True. We need to have a more nuanced term than simply  
"correct" in these emails.

>
>>>> 2) Would it be legal to attach the restrictions directly on the  
>>>> named
>>>> datatype instead of going through the (very verbose!) blank node,
>>>> e.g.
>>>>
>>>>       a:SSN rdf:type rdfs:Datatype .
>>>>       a:SSN owl:onDatatype xsd:string .
>>>>       a:SSN owl:withRestrictions ( _:y ) .
>>>>       a:SSN xsd:pattern "[0-9]{3}-[0-9]{2}-[0-9]{4}" .
>>>
>>> No. If you don't see a mapping rule to create or parse such  
>>> triples in
>>> the mapping document, then the construct isn't syntactically  
>>> correct.
>>
>> Correct in what language? It is perfectly legal RDF.
>
> It is perfectly legal RDF and that makes it perfectly legal OWL Full,
> apologies if there was confusion.
>
> I assumed that since he posted to the OWL list he wanted to know about
> how OWL parsers in general would see this. They would not parse it
> into the DatatypeDefinition that was cited, and any OWL tools that use
> the direct semantics would not process this construct.

Indeed.

>
>>> If you wrote the above it wouldn't mean what you intend it to mean.
>>
>> Can you elaborate on why not?
>
> Because he cited an example and asked if what was offered was a
> reasonable alternative encoding of that construct. The background was
> a question of best practices. The encoding offered is not semantically
> equivalent, even in OWL Full, and not part of the language OWL DL. I
> consider best practice to use the specified construct when there is
> one that matches intent, and in order to promote interoperability.

What I meant was, what inferences would go wrong. Not rhetorical, I  
was genuinely interested in the details. BUt let us take this offline  
or drop the subject.

>
>>
>>>
>>>
>>>> 3) Is it legal (and good practice) to subclass existing datatypes,
>>>> such as
>>>>
>>>>       a:SNN rdfs:subClass xsd:string .
>>>
>>> Not legal in OWL-DL. If you look at the reverse mapping the
>>> consequence of this is that a:SNN and xsd:string will be considered
>>> classes, not datatypes and that a term can't denote both a class and
>>> datatype.
>>
>> Which is absurd, of course. A datatype *is* a class in RDF. Still,  
>> OWL
>> is rich in such absurdities.
>
> Once there is a specification there isn't a question of absurd in the
> sense you suggest. The spec *defines* what the thing is.

True, but a definition can still be absurd. But let us not harp on  
this, my views on the awkwardness of the OWL-DL syntactic restrictions  
are well known.

>
>>> In OWL Full, this is allowed, but I wouldn't consider it good  
>>> practice
>>
>> I would. In what sense is a datatype *not* a class? It is defined to
>> be a set, after all.
>
> That's fine, but then your best practice would prevent the user who
> used the construct from making productive use of OWL-DL reasoners. I
> don't think *my* customers would find that good advice. Particularly
> as it seems unnecessary.

Well, it is very handy to be able to treat a datatype as a class, and  
the RDFS spec actually requires it. BUt of course, if one is aiming to  
use OWL-DL reasoners, then one should conform to OWL-DL, as you say. I  
guess I was reacting to the use of the term 'best practice', which  
seems to claim a degree of correctness which transcends  any one  
particular dialect. But perhaps you did not intend this broader sense:  
apologies for the misunderstanding.

Pat



>
> -Alan
>
>>
>> Pat Hayes
>>
>>
>>> - however perhaps Michael Schneider has a different opinion? ccing
>>> him.
>>>
>>> -Alan
>>>
>>>>
>>>> Thanks for clarifying these, so that we can built the best
>>>> practices into
>>>> our tools.
>>>> Holger
>>>>
>>>>
>>>>
>>>
>>>
>>
>> ------------------------------------------------------------
>> IHMC                                     (850)434 8903 or (650)494  
>> 3973
>> 40 South Alcaniz St.           (850)202 4416   office
>> Pensacola                            (850)202 4440   fax
>> FL 32502                              (850)291 0667   mobile
>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>>
>>
>>
>>
>>
>>
>

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Tuesday, 10 November 2009 16:45:31 GMT

This archive was generated by hypermail 2.3.1 : Wednesday, 27 March 2013 09:32:57 GMT