Re: Literals (Re: model theory for RDF/S)

Patrick, Pat, and interested readers,

allow me to add a tiny aspect to the voluminous and interesting
discussion led by you and others.

Patrick.Stickler@nokia.com wrote:
> 
> ...
> A string is a string is a string and the only thing we can
> deduce from it is that it is a sequence of bytes. Whether
> that sequence of bytes corresponds to a lexical representation
> of a numerical magnitude which we wish to classify as 'integer'
> is a matter of interpretation of the string. No such knowledge
> exists 'inherent' in the string itself, explicitly or
> implicitly.
> 
> So, any data type knowledge about a given literal value *must*
> be asserted in one way or another externally from that literal
> itself. Either by an anonymous node construct such as
> 
>    <rdf:Description>
>       <rdf:value>5</rdf:value>
>       <rdf:type rdf:resource="#integer"/>
>    </rdf:Description>
> 
> ...
> 
> ... one has to take deliberate steps to define
> the data typing in a way that can be utilized as knowledge
> explicit within the graph...


Hm, doesn't that allow for a nice and RDFish solution to the problem of
attaching properties to literals that can also be carried to the
semantics? Ok, let me try to demonstrate how this may solve the problem
of "Literals can not be in the subject position". 

To start, let me add an ID to the RDF expression above (to ease
reference to the RDF spec mainly, and to avoid the otherwise surfacing
necessity to explain why I do not buy into the treatment of anonymous
nodes in the MT (short for Pat's RDF model theory))

   <rdf:Description rdf:ID="five">
       <rdf:value>5</rdf:value>
   </rdf:Description>


The RDF spec says the following with respect to ID'd resources: 

"Such a resource might be a surrogate, or proxy, for some other
physical resource that does not have a recognizable URI."

Let's try to capture this spirit.

Now, I will fix the interpretation of Literals as follows: if E is a
literal, I(E) = E (or XL(E) if we fix XL to be E ;). (Pat, I need some
more emails to explain my motivation, so don't be too furious about this
now - the motivation is somewhat like the following: it considers
"literals" as the Urmutter of resources [in fact the only type of thing
that can be given a name in an RDF graph AND whose "content" is also
available ("literally") immediately], it is a way to communicate (parts
of) the mapping between resource names (URIs) and their actual "content"
from within RDF documents, which allows to ground (parts of) RDF in an
"processible" universe. Ah, ok, much explanation is still missing here,
but this is not the place to further advance this.)

Now, by giving the literal an "name", it is "promoted" to a resource (in
the sense of RDF: a resource is something that we have given an URI
name). We can now use the resource name in the RDF graph like any other
resource name - but more, we can even substitute the content for the
name along the extension of rdf:value (which we will first have to
capture appropriately) in the interpretation (and, in this respect, the
"literal" resource becomes a pretty "real" part of RDF statements). I
will do this in a two stage process:

Given a tidy, ground RDF graph E where all nodes that have outgoing
edges are labeled with URIs and all other nodes with URIs or Literals.

First (give an interpretation I' for the part of E that is relevant for
rdf:value)
* map literals l to itself with defining XL'(l) = l.
* map URIs u to itself with defining IS'(u) = u. Set IR' to be the set
of all URIs in the graph, and LV' the set of all literals in the graph.)
* Define IEXT' for rdf:value as follows: IEXT'(I(rdf:value)) =
IEXT'(rdf:value) = {<x,y>  |  <x rdf:value y> is in E }  (should be done
with labeled edges, triple notation considered a shorthand). Note:
assume that the inverse of rdf:value is injective.
* Determine I' as in the MT, with IS' and XL' instead of IS/XL (and
IEXT' restricted to rdf:value instead of IEXT)


Second (give an (partially fixed) interpretation for E))
* continue to map literals to itself (XL(l) = l).
* construct from the extension of rdf:value a mapping IS as follows:
IS(x) = y iff exists <x,y> in IEXT'(rdf:value), otherwise not fixed as
usual. (hm,  one may want to through out the (already "used")
rdf:value-related stuff from graph and interpretation because reduces to
identidy and does not seem to be anymore useful)
* Determine I as in MT.


Now, the triples resulting from 
    <rdf:Description rdf:ID="five">
       <rdf:value>5</rdf:value>
       <rdf:type rdf:resource="#integer"/>
    </rdf:Description>,
i.e. (leaving out reifications)
	<five rdf:value "5">
	<five rdf:type #integer>
will have a fixed part in each interpretation, let us denote this as
follows (to make it obvious)
	<"5" I(rdf:type) I(#integer)>   
(that is: the above triple set resp. the corresponding subgraph becomes
true, if <"5" I(#integer)> is in the extension of I(rdf:type) for a
given interpretation I.


Ok, now we can "RDFishly" (IMHO) say what we want about literals (and it
even has some sort of "accesible meaning ;). Ah, sorry, looks ugly and
does probably not communicate my intentions perfectly - but maybe it
adds a hopefully not too unreasonable opinion to the spectrum.

Thanks and best regards,
	Wolfram

	Wolfram Conen
	Xonar GmbH

[I am sorry, if what I wrote above is irrelevant or redundant, I just
returned from a longer journey caused by sad family matters and had no
time to read up all emails]

Received on Friday, 5 October 2001 10:06:55 UTC