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

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

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Sat, 18 Jun 2005 15:47:31 -0400 (EDT)
To: Geoff Chappell <geoff@sover.net>, "'Kenichi Taniuchi'" <ktaniuchi@tari.toshiba.com>, www-rdf-logic@w3.org
Message-Id: <20050618154731.CPU00496@isrmail.isr.umd.edu>

---- Original message ----
>Date: Sat, 18 Jun 2005 14:27:40 -0400
>From: "Geoff Chappell" <geoff@sover.net>  
>Subject: RE: How to add the constraining facets of  XML schema.  
>To: <bparsia@isr.umd.edu>, "'Kenichi Taniuchi'" 
<ktaniuchi@tari.toshiba.com>, <www-rdf-logic@w3.org>
>> -----Original Message-----
>> From: www-rdf-logic-request@w3.org [mailto:www-rdf-logic-
>> 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.

Well, our system (Pellet) does support derived, simple types, although there's no 
syntactic support, I suppose. Complex types would be nice, especially if we 
could do something more useful with XMLLiteral.

> 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

It's making it *equivalent* that's hard. XML Schema is a beast, after all.

That being said, you could have a subset in RDF. That's what Jeff does.

Getting all that exactly right is a bit of a bear.

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

Not always the wisest thing :) A little shyness might make RDF more attractive :)

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

Well, *on datatypes*. That's not RDFS reasoning, IIRC. There are pitfalls and 
rooms for interpretation.

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

Well, I still don't know your expected behavior, exactly. You do expect a clash if 
the integer is outside the constrained range, right?
>> 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


On the other hand, it's a bit easier in that I still would hand stuff off to the 
schema processer "as is" and the "location" problem that bedevils current 
approaches would be mitigated.

> - either some added vocabulary to tie a datatype description
>with a datatype or some means of referencing embedded xml frags). 

Yep, so, in the end, not hugely better. Maybe a tad cleaner semantically.

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

Oy! that sucks. XMLLiterals are much neglected :(

Which tool is that, btw?


Received on Saturday, 18 June 2005 19:47:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:44 UTC