Questions on RDF mapping of OWL 2 data ranges

[Holger Knublauch-2]

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?

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

3) Is it legal (and good practice) to subclass existing datatypes,  
such as

        a:SNN rdfs:subClass xsd:string .

Thanks for clarifying these, so that we can built the best practices  
into our tools.
Holger

[Alan Ruttenberg-2]

On Mon, Nov 9, 2009 at 4:06 PM, Holger Knublauch <holger@...> 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
>
>
>

[Pat Hayes]

On Nov 9, 2009, at 5:23 PM, Alan Ruttenberg wrote:

> On Mon, Nov 9, 2009 at 4:06 PM, Holger Knublauch <holger@...
> > 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.

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

> If you wrote the above it wouldn't mean what you intend it to mean.

Can you elaborate on why not?

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

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

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                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Bijan Parsia-3]

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  
spec.

> 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!

Cheers,
Bijan.

[Alan Ruttenberg-2]

On 11/9/09, Pat Hayes <phayes@...> wrote:

>
> On Nov 9, 2009, at 5:23 PM, Alan Ruttenberg wrote:
>
>> On Mon, Nov 9, 2009 at 4:06 PM, Holger Knublauch <holger@...
>> > 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.

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

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

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

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

-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                                     [phone] or [phone]
> 40 South Alcaniz St.           [phone]   office
> Pensacola                            [phone]   fax
> FL 32502                              [phone]   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>

[Michael Schneider-6]

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@... [mailto:public-owl-dev-
>request@...] On Behalf Of Alan Ruttenberg
>Sent: Tuesday, November 10, 2009 12:23 AM
>To: Holger Knublauch
>Cc: public-owl-dev@...; 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@...> 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  : [phone]
Fax  : [phone]
Email: michael.schneider@...
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.: [phone], Fax: [phone]
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
=======================================================================

[Pat Hayes]

On Nov 9, 2009, at 7:00 PM, Bijan Parsia wrote:

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

FWIW, I entirely agree :-)

Pat Hayes

> Hope this helps!
>
> Cheers,
> Bijan.
>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Pat Hayes]

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

> On 11/9/09, Pat Hayes <phayes@...> wrote:
>>
>> On Nov 9, 2009, at 5:23 PM, Alan Ruttenberg wrote:
>>
>>> On Mon, Nov 9, 2009 at 4:06 PM, Holger Knublauch <holger@...
>>>> 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                                     [phone] or (650)494  
>> 3973
>> 40 South Alcaniz St.           [phone]   office
>> Pensacola                            [phone]   fax
>> FL 32502                              [phone]   mobile
>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>>
>>
>>
>>
>>
>>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Holger Knublauch-2]

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@... [mailto:public-owl-dev-
>> request@...] On Behalf Of Alan Ruttenberg
>> Sent: Tuesday, November 10, 2009 12:23 AM
>> To: Holger Knublauch
>> Cc: public-owl-dev@...; 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@...> 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  : [phone]
> Fax  : [phone]
> Email: michael.schneider@...
> 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.: [phone], Fax: [phone]
> 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
> =
> ======================================================================