W3C home > Mailing lists > Public > www-webont-wg@w3.org > November 2002

RE: proposal: Structured Datatypes

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Thu, 7 Nov 2002 12:12:49 +0100
To: "Jonathan Borden" <jonathan@openhealth.org>, <www-webont-wg@w3.org>


does an XML structure datatype provide a value space?

The value of a literal with type rdfs:XMLLiteral is currently a minimal
canoncial xml document. If this value is inappropriate, one way to go would
be to propose on rdf comments that rdf:datatype be permitted with
rdf:parseType="Literal", (defaulting to rdfs:XMLLiteral) so that:

  <eg:prop rdf:parseType="Literal">
    <complex real='10.0'
"\n\t<complex imaginery=\"5.0\" real=\"10.0\"></complex>\n  "


  <eg:prop rdf:datatype="&my;complex" rdf:parseType="Literal">
    <complex real='10.0'


"\n\t<complex imaginery=\"5.0\" real=\"10.0\"></complex>\n  "

and my:complex is then a standard RDF datatype, but is expected to
informally inherit the technique for creating an XML document from the
canonicalized string.
Formally we may state that my:complex must have a mapping such that

For all strings x, y
if  rdfs:XMLLiteral( x ) = rdfs:XMLLiteral( y )
then my:complex( x ) = my:complex( y ).

For people who haven't been peeking, rdfs:XMLLiteral is a special datatype
defined in the latest draft of the RDF Concepts document (due out
yesterday - I am not clear what the hold-up is).
The value of a str and lang under this datatype is the document found by

<rdf-wrapper xml:lang="&lang;">&str;</rdf-wrapper>

I personally would support a well-worked out proposal, I believe rdf-core is
the correct forum, not webont. A partial proposal will be rejected because
of time pressure.

I believe that your current proposal is out-of-scope for webont because:
- all the features used are defined in RDF
- the use of rdfs:range for implicit datatyping has been considered and
rejected by RDF Core

i.e. this seems to me to be a reasonable idea about RDF, not about OWL.

If you wanted to make it easier to get RDF Core to accept your proposal, get
an XML Schema Datatype guru/author to second it ( ... are you one? genuine
question, no offense intended either way ... )


> -----Original Message-----
> From: www-webont-wg-request@w3.org
> [mailto:www-webont-wg-request@w3.org]On Behalf Of Jonathan Borden
> Sent: 06 November 2002 04:29
> To: www-webont-wg@w3.org
> Subject: proposal: Structured Datatypes
> I would like to propose a partial yet relatively simple and
> interim solution
> to the issue of Structured Datatypes. A full solution would involve
> 'grafting' the OWL class hierarchy onto the XML Schema type system i.e. an
> XML Schema type is considered a first class OWL class, and an OWL reasoner
> understands XML Schema type derivation composition etc.
> For the interim I propose when rdfs:range restrictions on
> owl:DatatypeProperty classes are URIs that identify XML datatypes (leaving
> alone for the moment the question about how one associates a URI
> with an XML
> datatype) that the lexical value of the owl:DatatypeProperty be an RDF
> datatype conforming to the syntax of rdf:XMLLiteral and that this fragment
> of XML be valid with respect to the particular XML datatype (e.g.
> XML Schema
> particle)
> For example suppose the XML Schema particle
> < xsd:complexType name =" xType " id="xType">
>  < xsd:sequence >
>    < xsd:element name ="a" type =" xsd:int " minOccurs =" 0 " />
>    < xsd:element name ="b" type =" xsd:string " minOccurs =" 0 " />
>  </ xsd:sequence >
> </ xsd:complexType >
> then (modulo base URIs)
> <owl:DatatypeProperty rdf:ID="xDTprop">
>     <rdfs:range rdf:resource="#xType"/>
> </owl:DatatypeProperty>
> and
> <rdf:Description rdf:ID="foo">
>     <ex:xDTprop rdf:parseType="Literal">
>             <a>123</a>
>             <b>asdaasd</b>
>      </ex:xDTprop>
> </rdf:Description>
> By this mechanism fragments of XML such as
> "<a>1234</a><b>asdasd</b>" which
> are valid w.r.t the type "#xType" and are considered
> individuals/members of
> the class "#xDTprop"
> Jonathan
Received on Thursday, 7 November 2002 06:13:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:04:37 UTC