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: Holger Knublauch <holger@topquadrant.com>
Date: Tue, 10 Nov 2009 09:25:00 -0800
Message-Id: <A1D956D7-36A0-498B-B6CC-757E9F9D4DE7@topquadrant.com>
To: public-owl-dev@w3.org
Ok, thanks everyone! I did not mean to stir up controversy here - I  
was simply asking for clarification because our users had similar  
questions. I believe we are all on the same page that a single syntax  
is better than multiple syntaxes for the same thing. As Bijan also  
states, this makes SPARQL queries (e.g. SPIN constraints) much easier.  
There are other places in the OWL spec that allow multiple syntaxes  
for essentially the same thing (e.g. owl:intersectionOf either  
directly or as equivalent class), and this has been causing confusion  
and makes implementations more expensive.

I think we also all agree that the current mapping is very verbose. I  
trust that there have been good reasons for this, and it's too late to  
change now anyway, so let's move on.

Regards,
Holger


On Nov 10, 2009, at 3:06 AM, Michael Schneider wrote:

> Hi Holger!
>
> Look at it this way: The option to assign names to datatype  
> restrictions was added to OWL 2 as a specific feature to allow the  
> reuse of complex datatype restrictions; this was requested by public  
> feedback, AFAIR. Therefore, the structural specification of OWL 2  
> has been extended by a dedicated construct for this feature, see  
> [1]. For the OWL 2 RDF mapping, it would have been perfectly valid  
> to introduce a new vocabulary term for this purpose as well, e.g.  
> something like
>
>  a:SSN owl:datatypeDefinition _:x .
>
> However, this was not necessary, since it was possible to re-use the  
> term owl:equivalentClass for this. On the one hand, for OWL 2 DL,  
> this was simply an extension to the (forward and reverse) RDF  
> mapping without leading to any conflict. On the other hand, for OWL  
> 2 Full, nothing needed to be changed, since the use of  
> owl:equivalentClass between two resources of type rdfs:Datatype is  
> allowed, anyway, and has the desired semantics out of the box. So  
> this "minimal change" path was finally chosen.
>
> Now, if you think, for a moment, in the lines of using specific new  
> vocabulary ("owl:datatypeDefinition"), it should become clear that  
> using something like "DT1 rdfs:subClassOf DT2" was not intended,  
> because there would have not been any additional  
> "owl:subDatatypeDefinition" term. And, in fact, using "DT1  
> rdfs:subClassOf DT2", with DT1 and DT2 being declared as datatypes,  
> is disallowed by the reverse RDF mapping, meaning that it does not  
> translate to any expression in the structural specification of OWL  
> 2, which again means that it is invalid OWL 2 DL.
>
> In OWL 2 Full, of course, you can freely specify sub class  
> relationships between any datatypes, but this is completely  
> independent of the datatype-definition feature. It is possible,  
> simply because datatypes are classes in OWL Full, and so you can  
> state anything about datatypes that you can state about classes. You  
> could do this already in OWL 1 Full, and even in RDFS you can safely  
> write
>
>    ex:MyDT rdf:type rdfs:Datatype .
>    ex:MyDT rdfs:subClassOf rdfs:Literal .
>
> and this is not only syntactically valid (it's well-formed RDF,  
> after all), but even has the expected meaning there: it defines some  
> datatype that is a sub class of rdfs:Literal, i.e. is a sub-datatype  
> of the datatype rdfs:Literal.
>
> The question is, what does such a sub datatype specification buy  
> you? Semantically, you only say with this that ex:MyDT represents  
> some set that may be anything between the empty set and the whole  
> original set of literals. This is extremely unspecific. At least for  
> datatypes, I think the interesting cases are those where you  
> *precisely* specify the extend of such a sub datatype. And this is  
> what datatype definitions in connection with facet-based datatype  
> restrictions are intended for in OWL 2.
>
> Now, to conclude, I would give the following advice: If Topbraid  
> Composer had no specific support for sub-datatype specifications in  
> the past, why should it have specific support for it now? The use of  
> "owl:equivalentClass" for datatype definitions should not mislead  
> you in thinking that OWL 2 has introduced general axioms on  
> datatypes. For OWL DL, this is definitely *not* the case. For OWL  
> Full, nothing new has happened except for the introduction of  
> faceted datatype restrictions. So I would say that OWL 2-aware  
> editors should really have dedicated support for datatype  
> definitions, since it is a particular OWL 2 feature, but no support  
> for anything else but this. Sub-datatype specifications were not  
> intended, and are not compatible with OWL 2 DL. Since Topbraid  
> Composer is an RDF-based editor, those people who believe that  
> building sub-datatype specifications is a good idea can still do  
> this by encoding the respective RDF bits manually, but this was  
> always possible in the past. If these people care about  
> interoperability with OWL 2 DL tools, they will be on the wrong  
> track, though.
>
> Cheers,
> Michael
>
> [1] <http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Datatype_Definitions 
> >
>
>> -----Original Message-----
>> From: public-owl-dev-request@w3.org [mailto:public-owl-dev-
>> request@w3.org] On Behalf Of Alan Ruttenberg
>> Sent: Tuesday, November 10, 2009 12:23 AM
>> To: Holger Knublauch
>> Cc: public-owl-dev@w3.org; Michael Schneider
>> Subject: Re: Questions on RDF mapping of OWL 2 data ranges
>>
>> 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/
>>
>>> 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.
>> If you wrote the above it wouldn't mean what you intend it to mean.
>>
>>
>>> 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.
>>
>> In OWL Full, this is allowed, but I wouldn't consider it good  
>> practice
>> - 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
>>>
>>>
>>>
>
> --
> Dipl.-Inform. Michael Schneider
> Research Scientist, Information Process Engineering (IPE)
> Tel  : +49-721-9654-726
> Fax  : +49-721-9654-727
> Email: michael.schneider@fzi.de
> WWW  : http://www.fzi.de/michael.schneider
> = 
> ======================================================================
> FZI Forschungszentrum Informatik an der Universität Karlsruhe
> Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
> Tel.: +49-721-9654-0, Fax: +49-721-9654-959
> Stiftung des bürgerlichen Rechts, Az 14-0563.1, RP Karlsruhe
> Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael  
> Flor,
> Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer
> Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
> = 
> ======================================================================
Received on Tuesday, 10 November 2009 17:25:46 GMT

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