Re: OWL datatyping and example


>This messages cites the discussion of datatypes in the RDF Core WG
>last call candidate working drafts, and gives an example of their
>possible use in OWL.

The comments are mainly about using RDF datatypes in OWL.


>rdfs:Datatype should replace daml:Datatype in OWL.
>Since rdfs:Datatype is a subclass of rdfs:Class, its instances can be
>used in an rdfs:range statement to indicate the class associated with
> given property (as in DAML+OIL), however
>Because the schema describes the range of this property as an xsd:integer,
>the value of the property must be a typed literal of that datatype in order
>to match the range description (i.e., the range declaration does not
>a datatype to a plain literal)
>]] [3]
>rdfs:range specifies a global restriction.  Hopefully we haven't done
>anything in OWL to break the use of local datatype restrictions in

Up to now we haven't, and we have both global and local restriction on
datatypes. On the one hand, in some circumstances it is convenient to be
able to use rdfs:range to set a global restriction. On the other hand, a too
strict global restriction can leave too little room for local restrictions.
So one should be very careful when he uses global restrictions.

In fact, in DAML+OIL when we define a datatype property, we can also set its
range for it. E.g.

<daml:DatatypeProperty rdf:ID="age">

>My own preferred style is to use local Restrictions exclusively for
>both datatype and object properties rather than global rdfs:range

Me too.

>One of my colleagues, Michael Cook, has been marking up the Periodic
>Table in DAML+OIL.  Converting one of his instances to OWL with
>datatypes yields:
><table:Element rdf:ID="He">
>  <table:name rdf:datatype="&xsd;string">helium</table:name>
>  <table:symbol rdf:datatype="&xsd;string">He</table:symbol>
>  <table:atomicNumber rdf:datatype="&xsd;integer">2</table:atomicNumber>

As far as we use typed literals, they are quite similar in DAML+OIL and OWL
(using RDF datatypes), e.g. in DAML+OIL the corresponding table:atomicNumber
property can be written as:

<table:atomicNumber><xsd:integer rdf:value="2"></table:atomicNumber>.

So the main difference is that in RDF datatypes, you can set the attribute
rdf:datatype as some datatype that is not an XMLS datatype, which may give
the users more choices than in DAML+OIL. Apart from that is the minor
difference of name space mentioned below - a more updated XMLS namespace is
used in RDF datatypes.

>assuming that xsd has been defined as an XML entity for
> (note that this is different than
>the namespace used in DAML+OIL).

>Note the use of the rdf:datatype attribute above to identify typed
>literals [5].  It has been suggested that simple literals (without
>rdf:datatype) could be used for the string values, but this precludes
>specifying rdfs:range or local restrictions on these properties
>(i.e. conveying the datatyping intentions of the ontology writer), so
>I don't find that good practice.

I agree - simple literals are redundant. It seems that the only use of them
are with rdfs:comment and rdfs:label etc. In RDFS interpretation,

rdfs:comment rdfs:range rdfs:Literal
rdfs:label rdfs:range rdfs:Literal.

It is very unusual to use typed literals as the range of rdfs:comment and
rdfs:label. And the reason that rdfs:comment and rdfs:label are included in
RDFS interpretation is because some constraints which apply to their use can
be stated using rdfs:range as above. [7] So the simplest solution might be
to abandon simple literals as datatypes, and keep rdfs:comment and
rdfs:label out of the interpretation (as that in DAML+OIL).

>Note that RDF provides for use of XML Schema datatypes, but also
>allows other type systems to be used:
>XML Schema datatypes have a "first among equals" status in RDF. They
>are treated no differently than any other datatype, but they are
>expected to be the most widely used, and therefore the most likely
>to be interoperable among different software. As a result, it is
>expected that many RDF processors will be programmed to recognize
>these datatypes. However, RDF software could be programmed to process
>other sets of datatypes as well.
>]] [5]
>DAML+OIL supported only XML Schema datatypes.

>Several additional notes:
>RDF provides no mechanism for defining new datatypes. XML Schema Datatypes
>[XML-SCHEMA2] provides an extensibility framework suitable for defining new
>datatypes for use in RDF.
>]] [1]

XML Schema Datatypes provides *an* extensibility framework suitable for
defining new datatypes for use in RDF. Other framework may also be used to
define new datatypes for use in RDF.


Other strange things with RDF datatypes include:

1) ICEXT(I(rdfs:Datatype)) = D : the interpretation of rdfs:Datatype is
equal to D, which is a set of recognised datatypes. This means if two
ontologies use different sets of recognised datatypes, the interpretation of
rdfs:Datatype will be different. It will be much safer if we say D <=
ICEXT(I(rdfs:Datatype)), i.e. the interpretation of rdfs:Datatype is the set
of all possible datatypes (like that in DAML+OIL), any recognised datatypes
are sub-sets of it.

2) The built-in datatype rdf:XMLLiteral, exceptionally, allows *pairs* in
its lexical space. And the set of recognized datatypes always includes
rdf:XMLLiteral. [6]









Received on Friday, 24 January 2003 06:14:46 UTC