W3C home > Mailing lists > Public > www-rdf-logic@w3.org > June 2005

RE: How to add the constraining facets of XML schema.

From: Geoff Chappell <geoff@sover.net>
Date: Sat, 18 Jun 2005 14:27:40 -0400
To: <bparsia@isr.umd.edu>, "'Kenichi Taniuchi'" <ktaniuchi@tari.toshiba.com>, <www-rdf-logic@w3.org>
Message-ID: <00db01c57433$69a85200$6501a8c0@gsclaptop>



> -----Original Message-----
> From: www-rdf-logic-request@w3.org [mailto:www-rdf-logic-request@w3.org]
> On Behalf Of Bijan Parsia
> Sent: Saturday, June 18, 2005 12:31 PM
> To: Geoff Chappell; 'Kenichi Taniuchi'; www-rdf-logic@w3.org
> Subject: RE: How to add the constraining facets of XML schema.
> 
> 
[...]
> >There's a good doc about xml datatypes and rdf at:
> >
> >	http://www.w3.org/TR/swbp-xsch-datatypes/
> >
> >Unfortunately, it doesn't offer an rdf-only solution.
> 
> I didn't quite understand that. Do you mean it doesn't offer a solution
> that
> doesn't require you to create an XML schema document? That's certainly the
> design choice for rdf datatyping in general.

Is it? I imagine most systems, if they support datatypes at all, are
supporting just the primitive types. I'd agree that if you want to support
arbitrary derived types, the only suggested approach is to somehow reference
an external xsd (the pitfalls of which are one of the main topics of the
best practices doc I mentioned). But while I appreciate the goal of re-using
xml schema datatypes in rdf -- for purposes of not reinventing the wheel and
general interoperability -- I don't see why there can't exist an equivalent
means to describe a datatype wholly within rdf (it is a _description_
language after all and certainly hasn't been shy about describing aspects of
itself in other regards).
 
> >In my own work I've done things like this:
> >
> >:myproperty a owl:DatatypeProperty;
> >	rdfs:domain :MyClass;
> >	rdfs:range [rdfs:subClassOf xsd:integer;
> >		xsd:maxInclusive "10"^^xsd:integer;
> >		xsd:minInclusive "1"^^xsd:integer]
> 
> I'd feel happier if you named the type, I guess.
> 
> >i.e. I create a derived datatype with appropriate facet restrictions as
> >needed. Most systems will likely not interpret the facets as meaningful,
> but
> >they should at least respect the base type.
> 
> I'd be surprised if they did!

You'd be surprised if they did something with the facets, or you'd be
surprised if they understood that any value of myproperty was a xsd:integer?
I'd hope that most reasoners would do the latter since it's just rdfs
reasoning.

 
> >I usually use the base type on
> >actual values - e.g.:
> >
> >	:x :myproperty "5"^^xsd:integer
> >
> >rather than naming the derived type and using that.
> 
> This sort of violates the "local" typing of properties. Hmm. Maybe not! As
> long
> as the actual value is in the intersection of the types, you probably
> won't get a
> clash.

Yeah, I don't think it does violate anything. That's the reason I kind of
like the approach - it degrades reasonably while providing useful info to
any system that happens to be able to make use of it.

 
> >I haven't seen this method used in the wild, so I gather it's not a
> >wide-spread practice.
> 
> Nope.
> 
> > Anyone else do anything like this?
> 
> There is something similar in Jeff Pan's extensions to OWL to allow for
> multiple
> arity datatype predicates and user defined types.
> 
> > Or see reasons not
> >to?
> 
> I'd be surprised if this became a sanctioned solution.
> 
> I've thought of embedding fragments of XML schema in rdf documents (via
> XMLLiterals) which at least sortof respects the "use Schema for datatype
> specification" while giving us "one document/local" datatype definitions.

Yeah, this has an appeal also (though it currently would have to rely on
convention also - either some added vocabulary to tie a datatype description
with a datatype or some means of referencing embedded xml frags). I chose
not to go this route because my tools currently can't look inside xml
literals during the reasoning process (except by treating them as strings).
 
> Cheers,
> Bijan.

Best,

Geoff
Received on Saturday, 18 June 2005 18:27:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:50 GMT