- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Tue, 16 Oct 2001 17:49:05 -0500
- To: Jan Grant <Jan.Grant@bristol.ac.uk>
- Cc: w3c-rdfcore-wg@w3.org
>On Tue, 16 Oct 2001, Pat Hayes wrote: >.... >First, there are two separate issues/proposals which can be discussed > > separately, though they do fall naturally together: >> >> 1. Provide a way to allow two different occurrences of the same >> literal to be distinguished in the syntax. (must-do) >> >> 2. Allow literals as subjects. (optional) >> >> Let me focus on the first as it is the most important. > > >> In the current draft of the MT document, RDF graphs are required to >> be 'tidy', which is defined to mean that labels uniquely identify >> their node, ie no two nodes have the same label. "Label" here refers >> to both urirefs and literals; that means that, with this definition, >> any literal can occur in a graph only in one place, labelling one >> single node. >> >> This is not acceptable if we are ever going to allow nontrivial >> datatyping, since (if we do) that would mean that we will want one >> occurrence of a literal to mean one thing, and a different occurrence >> to mean something else, so we cannot require that they be the same >> occurrence in the graph. (Exactly how the different occurrences of, >> say, "010701" are inferred to be of type integer, or string, or date, >> or whatever, is another issue that we can discuss separately; the >> present point is only that different occurrences of the same literal >> might be somehow treated differently, so cannot be forced to be >> syntactically identical.) So, if we have (or even contemplate the >> possibility of some extension of RDF ever having) nontrivial literal >> datatyping, then we have to relax the strict tidiness condition on >> literals, and allow the same literal label to appear at several >> places in the graph. > >No; because we can consider the typed datum to be the literal, not its >(unicode) representation. Ok, what IS a literal, exactly? Please write a few of them down so I can see them, if you would be so kind.... They have to be things that we can include in Ntriples documents and use as graph labels. If you mean that the literal IS something like an externally tagged label, where the tagging is included as part of the literal, then that is what I originally had in mind when writing the MT, but that has been strongly rejected by others. >These are all distinct wherever we need them >to be, and the "same" for the purposes of tidyness where we need them to >be. So what exactly is the label in the graph? You seem to be saying that the problem just goes away by magic if we say that two things are the same and also not the same. >If you do this the problem you describe goes away (I think). I think that is the solution I originally had in mind. However it does not seem to be acceptable to most people, in particular to the DAML folk, and it doesn't seem to match up with the general usage of 'literal'. Also it is still a hedge around the basic problem, which is that insisting on uniqueness of literals is a lot less reasonable than for urirefs, and is liable to lock us into a box we would rather not be in, and there is no real RDF reason why we need to. We invented Ntriples ourselves, right, so we can re-invent it just as easily. > >> OK, that's the pressing matter. The other matter is less pressing. If >> we were to allow literals as subjects, then this proposed extension >> to the Ntriples syntax could also be used to specify graphs in which >> datatyping information was specified directly, by simply asserting >> that a (particular occurrence of a) literal has a datatype as its >> rdf:type. (see >> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Oct/0277.html >> ) > >This is an interesting point. What I'm suggesting is that there is an >"inherent type" associated with a literal. This is distinct from any >assertions made in a graph. The type has to be associated with a particular *occurrence* of a literal, and the only thing we have in the graph syntax to distinguish one of these from another is the node it is attached to. If there is going to be *any* kind of way to indicating the datatype of a literal by some means in the graph, then we cannot have the literal typing done by the literal label itself. In any case, putting datatype information into the label is just as much an extension to the current language; and this generalization would not rule it out; so this keeps our options open. >We can go one step beyond a model theory by >talking about categorising which interpretations we consider to be >valid; for instance, we might require that > > integer(23) <rdf:type> <xsd:Integer> . > >should be ok in all valid interpretations, but > > integer(23) <rdf:type> <foo:NegativeInteger> . > >should not be. This IS model theory; you are stating semantic conditions on an interpretation. But look: what is integer(23) here? A literal? If you can tell that its an integer by looking at it, what do you need that triple for? And if that triple is true, does _:xxx <rdf:type><xsd:Integer> . have to be entailed by it? If its not a literal, what is it? >This becomes less of a problem if you adopt the notion of >multiple "literal instances" as was recently suggested. Maybe I missed that. Pointer? > >> This would provide a simple, obvious mechanism for declaring >> datatypes which would integrate smoothly into both the (extended) RDF >> syntax, and also the proposed model-theory treatment of datatypes. >> (sketched in >> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Oct/0164.html ) >> And I can see no rational reason to prohibit it, other than it >> possibly being beyond our charter. So this seems to me to be some >> extra support for the proposal to allow literals as subjects. >> (However, even if this proposal is rejected, the previous point >> stands on its own. ) >> >> I hope this covers the issues adequately. >> >> Pat >> >> > >-- >jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ >Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk >"My army boots contain everything not in them." - Russell's pair o' Docs. -- --------------------------------------------------------------------- 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 Monday, 22 October 2001 10:10:50 UTC