- 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
---- 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.
Received on Saturday, 18 June 2005 19:47:50 UTC