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

RE: Subject literals

From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Date: Mon, 05 Nov 2001 13:47:09 +0000
Message-Id: <5.1.0.14.2.20011105131823.03891090@joy.songbird.com>
To: Patrick.Stickler@nokia.com
Cc: w3c-rdfcore-wg@w3.org
At 02:54 PM 11/5/01 +0200, Patrick.Stickler@nokia.com wrote:
> > >E.g. consider the following simple example:
> > >
> > >    "fi" <rdf:type> <urn:iso:3166_1> .
> > >    "fi" <rdf:type> <urn:iso:639> .

[...]

>Whether they get merged or not in the graph is IMO
>not the point -- but they would get merged (implicitely
>or explicitly) in the results of some query, no?

Not necessarily.

>If I conduct a query and get the value of some property
>as "fi" and then go to get the properties of "fi" I
>would expect to get both of the above statements.

Yes.

>So, whether there is one node with two types,
>or two nodes each with one type, I still am not getting
>the distinction I need.

I think you're getting what distinction there is, which may or may not be 
what you need.

Roughly speaking, I'd interpret the above response to mean something like this:

There is a node labeled "fi", whose type is <urn:iso:3166_1>.  (That is, 
the denotation of the node is a member of the class extension of the 
resource identified by <urn:iso:3166_1>.)

There is a node, which may or may not denote the same value as the first 
node, whose type is <urn:iso:639>.


>The fact is that "fi" is being used to represent distinct
>things, and as such, should be a URI in both cases
>and not a literal.

I'm not sure exactly how to interpret your phrase 'is being used to 
represent', but it seems to carry implications of uniqueness that are not 
present.  I'd find 'is being used to label' a closer description.

I think a literal string *alone* does not uniquely represent any value, 
except maybe itself.  One also needs some rule of interpretation to find 
the value it denotes.  The original model theory proposed that the same 
rule of interpretation was used for every occurrence of a given literal 
string.  The revised approach allows different rules to apply to different 
occurrences.

>I must really be missing something, but I just don't see
>the utility of allowing literals to act as subjects (even
>if only deep in the bowels of the graph semantics).

(see below)

>If you are somehow attaching contextual information to
>those nodes labled "only" with literals, then you are not
>actually labling only with literals, but with a complex
>cluster of information ...

So far, so good.  But why the hang-up with "only"?  If a literal label is 
the only information you have about a node, that is a limitation on what 
you know.  If you know other things, then that may allow you to read deeper 
meaning about the literal value.  That sort of thing is exactly what 
happens, for example, with CC/PP (see separate message).

>... providing the equivalent really
>of URI like indentification, and then what are the
>conventions for using that contextualization in my queries
>to separate "fi" the language from "fi" the country?

I dispute that it's the *equivalent* of URI-like identification.  A 
particular lexical -> data value mapping is defined independently of any 
interpretation used, even though the interpretation may indicate *which* 
such mapping applies in any particular case.  Also, unlike interpretation 
of URIs, a *different* lexical -> data value mapping may be invoked by 
different nodes in a graph under a single interpretation.

The utility of all this, I think, is that it allows us to capture formally 
the meaning of some of the ways in which RDF literals are being used in 
practice.

#g


------------------------------------------------------------
Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
<Graham.Klyne@MIMEsweeper.com>
------------------------------------------------------------
Received on Monday, 5 November 2001 08:52:33 EST

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