Re: Questions on RDF mapping of OWL 2 data ranges

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.

>>> 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                                     (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 01:34:01 UTC