- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Wed, 7 Nov 2001 15:36:19 -0600
- To: Patrick.Stickler@nokia.com
- Cc: w3c-rdfcore-wg@w3.org
> > The way of interpreting the >> strings goes along with the class, not with the things in the >> extension of the class. If we know that we are supposed to treat the >> thing as being in a class which is a datatype class, then we know how >> to interpret any literals that might denote it. > >Exactly. > >> That information is >> associated with the class, not with the thing. Hence the Ntriples++ >> triple: >> >> lit rdf:type <datatypeClass> . >> >> says exactly what it ought to say; eg >> >> "21" rdf:type xxd:octalNumber . >> >> tells us that the literal denotes 17, which is exactly what >> >> "17" rdf:type xxd:decimalNumber . >> >> also tells us. > >Although I agree with the spirit of the above >statements, I am still a bit puzzled by the fact >that the literal is acting as the subject. Well, I took a liberty here, to make my point. This isn't legal RDF. >Surely >we are not saying that all occurrences of the literal >"21" are of type xxd:decimalNumber, are we? No; we are saying that THAT particular occurrence is. That is why datatype reasoning has to be defined with respect to nodes in the graph, rather than literal labels. >Rather, we are saying there is some value X that has >a lexical form "17" and is of the type xxd:decimalNumber. > >I.e. > > #X rdf:value "17". > #X rdf:type xxd:decimalNumber . > >The fusion of literal as subject really confuses me I concede it is a little shifty because it relies on an intensional reading of the class. Think of the type information as saying 'this value is being treated, here (ie on this node), as being in a class which is associated with a particular datatype mapping, viz. xxd:decimalNumber.' >(an easy thing to do, I'll admit ;-) > >Subjects are resources which have unique global identity >represented by a URI. Nonsense. First, there is no 'unique global identity'; the same URI can be used to identify many different entities at different times, and the same thing, sorry, resource, can have many URIs. Second, a literal can denote the same thing as a URI can (you had better admit this is true if you want URVs to be URIs), so even if the value can be referred to by a URI, it can also be referred to by a literal. I see no rational reason why one kind of name should only be used in one kind of place. >Literals are not URIs, so how can >they serve as subjects. Literals denote values in the same away that URIs do, so why can they not serve as subjects? (?? You seem to be assuming that the only way to refer to something is to use a URI, maybe? But in that case, why do you not object to using literals as objects?)(Added later: Ah, you do. OK, I give you consistency :-) >If you are using the form > > "17" rdf:type xxd:decimalNumber . > >simply as a syntactic convenience, meaning that somewhere >underneath that literal is in fact a node with globally >(or at least system) unique identity, fine, but that is >rather confusing IMO. Why is that confusing? The RDF syntax is defined over nodes. Every subject or object in any piece of RDF is attached to a unique node with a unique identity. That is a basic fact of RDF syntax, and its rather a nice one, so why waste it? >After all, we are talking about a value here, not a given >lexical form, and the value has both a type and lexical >form, thus the anonymous node #X represents the value, >not the literal. Eh? I don't want to even use the anonymous node at all. I want the literal to BE a string and to DENOTE its literal value (eg in this case, a number). Just like urirefs ARE strings and DENOTE resources. >And so long as we must represent that >value in terms of a lexical form, we need to have a consistent >and persistent construct to tie form and type together Well, we need to be able to reliably infer it, I would say. > which >will endure across operations such as inferred binding to >properties of superordinate or equivalent types. Thus we >need to have that anonymous node (or some other encapsulation >such as a URV encoding). No, that does not follow. Pat -- --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes
Received on Wednesday, 7 November 2001 16:36:22 UTC