- From: Jonathan Borden <jonathan@openhealth.org>
- Date: Fri, 29 Oct 2004 17:07:36 -0400
- To: Chris Lilley <chris@w3.org>, www-tag@w3.org
Chris Lilley wrote: >With the proviso that I would prefer > >data:text/plain;charset="utf-8",some%20percent%20escaped%20literal%20value > >It seems a perfectly fine way to define a literal. Its also a URI, its >moderately compact, the network performance is very good :) it has a >defined media type, its clear exactly what the representation is, its >clear that its always available and does not vary by media type, >referer, time of day, etc. > > This does seems reasonable but would require some changes to RDF that probably could be worked out but might be less straighforward than you might initially suspect. The "new" RDF literals are binary, i.e. consist of a string literal followed by a "^^" and then a URI datatype. So somehow that would need to be fit with data: URIs. There might be other issues with OWL. As I recall, one of the reasons to distinguish between owl:ObjectProperty (URIs) and owl:DatatypeProperty (literals) is that there are some issues in reasoning when regarding integers as URIs. For example suppose one restricts the rdf:range of a particular datatype property to "xsd:positiveInteger". Without special knowledge (e.g. of integer arithmetic) you would need to represent the datatype class as an infinite set of data: URIs... typically a reasoning engine handles such XSD datatypes as special cases i.e. falls out of strict FOL/DL. I suppose such engines could parse URIs, but somehow we would need a way to embed a datatype specifier in the data: URI. Not impossible but not entirely trivial either. Jonathan
Received on Friday, 29 October 2004 21:07:44 UTC