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: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Tue, 10 Nov 2009 01:00:12 +0000
Cc: public-owl-dev@w3.org
Message-Id: <754154E6-EF8D-4ECF-B502-1868E09B11A7@cs.man.ac.uk>
To: Holger Knublauch <holger@topquadrant.com>
On 9 Nov 2009, at 21:06, Holger Knublauch 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?

This would make you OWL Full (I'd imagine) and might screw up some   
parsers/translators (e.g., the OWL API) and validators. Obviously, it  
would also complicate e.g., datatype extraction code that e.g., used  
SPARQL 1.0 (since they would have to check for two cases rather than  
one, at least).

I imagine, eventually, repair code would fix that up, but I think it's  
more robust for code to stick closer to the explicit behavior of the  

> 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}" .

The main reason for the verbose form is partly consistency with class  
expressions and axioms and partial to make it easier to verify the  
naming constraints (e.g., avoiding cyclic patterns of dependency).

Again, this won't accord with tools following the spec and trying to  
be DL compatible, so if you can avoid it, it will increase interop.

(Since they are named I think the verbosity isn't so bad (occurs once  
per def) and, if generated by tools, not burdensome.)

> 3) Is it legal (and good practice) to subclass existing datatypes,  
> such as
> 	a:SNN rdfs:subClass xsd:string .

This will only make sense in OWL Full, but it could have surprising  
results and won't work well with XML Schema based datatype reasoners.  
I think its better, as a general rule, to use the XML Schema based  
derivation operators to define restrictions on existing datatypes.  
It's easier to go back and forth with the XML Schema syntax, which I  
think is a good idea.

Speaking as a repository builder (and other tool builder), I'd be  
happier if your (and everyone's!) tools generated RDF that's close to  
the RDF mapping, even if it's somewhat verbose. Consistency makes  
things a lot easier down the line.

Hope this helps!

Received on Tuesday, 10 November 2009 01:01:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:58:18 UTC