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

RE: Subject literals

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Mon, 5 Nov 2001 20:47:31 -0600
Message-Id: <p05101034b80cfbf413ba@[]>
To: Patrick.Stickler@nokia.com
Cc: w3c-rdfcore-wg@w3.org
>  > -----Original Message-----
>>  From: ext Graham Klyne [mailto:Graham.Klyne@MIMEsweeper.com]
>>  Sent: 05 November, 2001 14:13
>>  To: Stickler Patrick (NRC/Tampere)
>>  Cc: w3c-rdfcore-wg@w3.org
>>  Subject: Subject literals
>>  At 11:51 AM 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> .
>>  >
>>  >One defines a language, the other a country. Yet these
>>  >get merged into ambigous "knowledge" about the subject "fi".
>>  Not according to the revised model theory proposals.  Literal
>>  strings would
>>  graph node labels, and the same literal string label could be
>>  used on more
>>  than one such node (a relaxation of the "tidy graph"
>>  requirement).  For
>>  each node, there would be a single meaning (denotation) in any given
>>  interpretation.
>>  That is, the "fi" nodes do not get merged.
>>  #g
>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?


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

No, that would be invalid. You should make that assumption only for 
urirefs. If you were to return to the vary same literal *node* you 
could make that kind of inference, but (in the absence of confirming 
datatype information) you cannot in general assume in RDFS that two 
literal labels on different nodes denote the same thing. Since we 
insist graphs are tidy on urirefs, this can be summed up by saying 
that identity is determined by the node. Any two different nodes are 
at risk of having different denotations.

>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 the node distinction is exactly what you need.

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

Why does that follow?

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

It allows one to say that a particular literal has a certain datatype 
directly, is all. Rather than transcribing

aaa eg:prop 10

into the form

aaa eg:prop _:x
_:x rdf:type xsd:integer
_:x rdf:string "10"

you can simply construct the 2-edge 3-node graph

aaa ---eg:prop--->10--rdf:type--->xsd:integer

where the _:x blank node isn't needed, since the literal node can be 
its own subject, and the rdf:string link isn't needed at all, since 
the fact that the string '10' denotes the value that it does it just 
part of the graph semantics itself: you don't need to talk about your 
own syntax when its there on your nodes already.

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

The node itself provides the locus to which the datatyping 
information applies (in the proposed MT extension, at any rate. You 
realize of course that you have walked into the middle of a battle, 
and that shrapnel is flying all around you?)

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Monday, 5 November 2001 21:47:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:53 UTC