W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > October 2001

Re: Literals as subjects, labels for nodes

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Tue, 16 Oct 2001 17:49:05 -0500
Message-Id: <p0510102db7f24257c057@[205.160.76.193]>
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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:41:08 EDT