- From: Dave Reynolds <der@hplb.hpl.hp.com>
- Date: Thu, 23 Aug 2007 09:54:38 +0100
- To: Bijan Parsia <bparsia@cs.man.ac.uk>
- CC: Reto Bachmann-Gmür <reto@gmuer.ch>, semantic-web@w3.org
Bijan Parsia wrote: > > On 22 Aug 2007, at 11:23, Dave Reynolds wrote: > >> Bijan Parsia wrote: >>> RDF has pretty limited datatype support in general (both in the spec >>> and in the tools...as far as I know). >> >> I thought most RDF tools supported a good range of XSD types. > > I don't have a list, hence the caveat. What's a better > statement....Well, it seems clear that any conforming RDF parser should > respect arbitrary datatypes in assertions, at least in the sense of > providing access to the datatype URI and the lexical form. I believe > that most if not all of them do that. An RDF application (including a > store) could choose to normalize the lexical form if it respected the > value. I don't know what most systems do there. What I'm skeptical about > is whether there is general support for D-Entailment (I'd expect at > least a warning by a reasoner if a particular datatype were unknown to it). Fair comment. There was a workshop on RDF store implementations in Amsterdam several years ago. Most of the implementers at that workshop provided some form of normalization and equivalence testing for the main XSD types. In our case we retain both the original lexical form and a normalized value form for the typed literal so that you can test equality of values ("01^^xsd:int = "1"^^xsd:integer) without losing round tripping. However, none of them implemented the bNode "allocation" part of the D-entailment rules. I can't remember if handling of unknown datatypes was explicitly discussed. In Jena's case there is a configuration option to determine if an unknown data should be passed through or raise a warning. >> Jena also supports user defined types - both user defined XSD types >> and generic user defined types. A type URI which is not recognized >> will by default pass through safely (you can parse it, serialize it, >> get it's lexical form etc) so the minimum you need to do is to invent >> a URI for your datatype. > > Yes, there's an ambiguity in "supports". Sorry 'bout that. I was > thinking primarily about "supports the value space and entailments wrt > it". Seems like Jena does some of that too. Indeed it does. >>> OWL has somewhat better support including required support for >>> xsd:string and xsd:integer, plus at least defined support for other >>> simple types: >>> <http://www.w3.org/TR/2003/WD-owl-semantics-20030203/syntax.html#2> >>> Deriving URIs for user defined datatypes was left unspecified in >>> deference to the XML Schema working group. There's a discussion you >>> might find interesting: >>> <http://www.w3.org/TR/swbp-xsch-datatypes/> >>> (Pellet implemented the daml solution.) >> >> As does Jena. > > Sorry, do you mean that Jena implements the daml solution? Yup. > That's nice. > We should have a list somewhere (heck, for all I know, pellet's support > is derived in part from Jena!). > > Does Jena also support the OWL 1.1 RDF vocabulary for defining > datatypes? (Not that I'm convinced that this is, in general, a good idea). No, at least not yet. We're not yet convinced that such replication of XSD inside OWL is appropriate, though can see some benefits. If it survives the working group process then it'll get higher on the implementation wish list :-) Dave -- Hewlett-Packard Limited Registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England
Received on Thursday, 23 August 2007 08:55:01 UTC