RE: Subject literals

> 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>.

OK. Fair enough. The fact that you are getting two nodes
as the result of a query at least suggests that some degree
of ambiguity exists, but are you saying that *every* instance
of a literal value gets its own bNode onto which one can
hang type and other properties?

How does 

   <urn:foo> xyz:someProperty [ rdf:value "fi"; rdf:type <urn:iso:3166_1> ]
.

get to

   <urn:foo> xyz:someProperty "fi" .
   "fi" rdf:type <urn:iso:3166_1> .

And if 

   "fi" rdf:type <urn:iso:639> .

also exists, how do I know *which* "fi" is the actual
value of xyz:someProperty? OK, if range is defined
for the property, then perhaps that could help
disambiguate.

I just don't see the utility of using the literal value
as the label of a node. What is it *really* buying us
here?
 
Data typing of literals is a context-sensitive thing, because
literals are ambiguous.

To treat literals as node labels is to introduce that
ambiguity into the graph. Why? How is that any more
flexible or useful than bNodes?

> >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.

In essence, the local type is acting as a kind of namespace
for the literal, to differentiate it from other equivalent
literals belonging to other namespaces.

I.e. what we really have is (urn:iso:639)fi and (urn:iso:3166_1)fi
which are distinct "things" (abstract, yes, but distinct).

> 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).

I am still obviously missing something. 
 
> (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).

Right, but that additional information is contextual, not
a property of the literal string itself. In other words, a
typed anonymous node is just that, a typed node. It is a
lexical form which is given that interpretation. The interpretation
is not a quality of the form itself, but of the "thing" 
denoted by that lexical form.

Thus "fi" is just a string, but 
[ rdf:value "fi"; rdf:type <urn:iso:639> ] is something more,
yet it exists only within the context of a particular
statement.

The <urn:iso:639>'ness of "fi" is not a global property of
"fi", but only of a particular instance of "fi".

Breaking

   <urn:foo> xyz:someProperty [ rdf:value "fi"; rdf:type <urn:iso:3166_1> ]
.

into

   <urn:foo> xyz:someProperty "fi" .
   "fi" rdf:type <urn:iso:3166_1> .

just doesn't make sense to me. You're losing the
context that makes the type classification valid and
meaningful.

Still obviously not "getting it"...
 
> >... 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.

I mean, if you are associating information about each node
such that no two nodes have identitical information, then you
have the equivalent of a URI, though I'm still puzzled about
how you would unambiguously relate the object literal of
the statement with its qualified form using the literal as
the node label....
 
> 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.

In practice? I'd appreciate seeing examples. My guess is that if 
literals are being used in ways that would enable them to
act as the subjects of statements that you have a pretty
closed system where there exists no ambiguity between any
literals (i.e. they are the equivalent of URIs for all
practical purposes) or the degree of ambiguity is so small
that it is easy to program around it.

But maybe I'm still just missing the whole point... sorry
for being particularly thick today...

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Monday, 5 November 2001 09:32:08 UTC