---- 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-
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.
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?
Both.
>I'd hope that most reasoners would do the latter since it's just rdfs
>reasoning.
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?
[snip]
>> 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
Yep.
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?
Cheers,
Bijan.