- From: Joshua Allen <joshuaa@microsoft.com>
- Date: Thu, 17 Mar 2005 08:34:01 -0800
- To: <jsled@asynchronous.org>
- Cc: <semantic-web@w3.org>
> the impression that data-typing serves as a mechanism to identify the > process to convert a string representation into a particular value. Well, that's a bit of a simplification. Using the Jerome Simeone definitions, the following applies: * type assignment: take a string and parse to an atomic value or list of values * type erasure: take atomic value or list of values and serialize to a string * type mapping: take one atomic value or list of values and convert to another atomic typed value or values. Note that there is such a thing as an atomic typed string, and that it is NOT the same as type erasure to map from int to string, and NOT the same as type assignment to map from string to int. Now, in danger of being accused of lecturing myself, I want to point out why URIs are special. First, look at the definition of typing above, and think about complex XML types versus literal types -- as you are *parsing* the XML elements, you could be assigning a type -- then at some point you hit a literal, and you parse *into* the literal and also assign a type. The point is, there is nothing special about "literal" types. All of them need to be *parsed*. It is entirely conceivable that you could define a literal type called escaped-rdf-document, with the expectation that this would be parsed into a full RDF document, itself containing literals. So therefore, in response to: > In the explicit case, it would seem weird to me that all other typed > literal values (int, float, "number", "base64-jpeg", &c.) would use the I say, why are you treating some literals as being more literal than others? It is common practice in the XML world to embed XML document literals in text nodes. Just because XSD spec decided to define one particular literal hierarchy does not mean it is sent from heaven; in fact most people admit that the literal hierarchy has some serious flaws (look at int vs. integer vs. long for example). My point is that literals are no different from any other blob which needs to be parsed and typed -- for example RDF/XML and n-triples. Literals sort of "import" a type system into RDF which is not there. You cannot parse out any arbitrary literal type scheme just by implementing the RDF specs. Each new literal type is a new parsing code. On the other hand, URIs require no type at all. They are universal identifier. URIs are the words of the Internet. They are opaque; need no parsing to use, and so on. > As counterpoint to your "we don't need URIS anywhere!" msg [1], should > all values become a URI? My answer would be, if the value *can* have a URI, it should. This makes the value accessible to people with the bare minimum RDF support (and doesn't break OWL by the way). But I admit there is a slippery slope somewhere. For example, would I recommend that we do something like http://xmlns.org/numbernet/integers/2500? No way! I see no value in having a URI there. But true/false makes sense to me -- it's a value you use almost exclusively for equality comparisons, and URIs are designed for nothing if not equality comparison. Things like date-time and integers are used in less-than, greater-than comparisons and arithmetic -- that's clearly not a URI use case.
Received on Thursday, 17 March 2005 16:34:06 UTC