- From: Geoff Chappell <geoff@sover.net>
- Date: Fri, 19 Oct 2001 09:57:04 -0400
- To: "Brian McBride" <bwm@hplb.hpl.hp.com>, <www-rdf-interest@w3.org>
----- Original Message ----- From: "Brian McBride" <bwm@hplb.hpl.hp.com> To: <www-rdf-interest@w3.org> Sent: 10/18/2001 2:10 PM Subject: RDFCore Update > One major area of focus for the WG at the moment is datatyping, e.g. using XML > schema datatypes in RDF. Now would be a good time to let us have your thoughts > and ideas on this. > > Brian It seems that the purist approach is to add "compound objects" - i.e. typed anonymous nodes with rdf:values. This method allows infinite type extensibility, but will certainly lead to node bloat and real-world application performance will undoubtedly suffer. The alternative often suggested is to pack datatypes into the values themselves (through various uri schemes). This seems to me more like a serialization solution than a datamodel solution. Do we really want to put the burden on applications of parsing uris to extract type info and values? There doesn't seem to be much discussion about just surfacing a primitive type attribute for each node on the RDF graph. Why not? After all, it's implicitly already there. Despite the fact that RDF's current don't ask, don't tell policy on literals prohibits you from asking whether a node is a literal or declaring that it is, a node either is or isn't. The reality is any non-trivial rdf processing application needs to know the type (literal or resource) of a node and is encoding that fact in some manner (just look at all the graphs on the w3c site and elsewhere - the nodes are different shapes; where is that information encoded in the rdf model?). Why not just explicitly add an attribute so we can say a node is a resource (aka an object), string, int, double, or datetime. In the future (soon hopefully) the attribute could also say whether the node is an anonymous resource (a variable), a list, or some other type of core language component. Presumably it would be the task of an RDF query language or API to expose these primitive types. This just seems like a natural compromise between purity and pragmatism that any successful programming language has to make. rgds, Geoff Chappell
Received on Friday, 19 October 2001 09:59:59 UTC