RE: Subject literals

> Right. YOu need to extend the Ntriples notation slightly to be able 
> to fully capture the structures that can be built. One proposal 
> (still not adopted) is to allow nodeIds (the new name for the _:x 
> labels) to identify not just blank nodes but also literal nodes. So 
> one might write the graph I had in an earlier message:
> 
> aaa ---eg:prop--->10--rdf:type--->xsd:integer
> 
> could be written in Ntriples++ as:
> 
> aaa eg:prop _:1:"10" .
> _:1 rdf:type xsd:integer .

Well, now I'm just gonzo confused (a common state for me these
days is seems ;-)

Exactly what is the difference between this "new"
representation 

  aaa eg:prop _:1:"10" .
  _:1 rdf:type xsd:integer .

and

  aaa eg:prop <genid:123> .
  <genid:123> rdf:value "10" .
  <genid:123> rdf:type xsd:integer .

aside from the fact that the literal value is now part 
of the *unique* identifier?

And since the label of the node is now unique, why
then not use a URI.

I.e. why not just

  aaa eg:prop <xsd:integer:10> .

and be done with it?

Interpretation of literals is for applications above the RDF
space anyway, right? So why not just use a self contained package
of value and type, which doesn't get munged when binding to
query variables employing inference based on subClass relations?


> where the subject of the second triple is the same nodeID as the 
> object of the first one. The general rule to make a graph from such a 
> document is: make a separate graph for each triple, then merge all 
> nodes with the same nodeID or uriref label; then erase the nodeIDs.
> 
> Now, the examples given above might look like this:
> _:1:"fi" rdf:type <urn:iso:3166_1> .
> _:2:"fi" rdf:type <urn:iso:639> .
> <urn:foo> xyz:someProperty _:1:"fi" .

Well, that's *alot* different than the earlier examples
which had the object nodes labled identically. This treatment
seems the same to me as the current "genid:" approach
which of course is required in order to get to triples.

Each bNode has a "system" identity, and statements are
expressed using that system identity as the subject. And
in essence, that system identity is a kind of "local URI".
So your label really *is* the same as a URI, but it's
the URI of a resource node (or bNode) not the literal itself,
and properties (arcs) hung on that node are properties of
the object for that particular statement, not the literal.

Thus, to that end there is no functional difference
between

 _:1:"fi" rdf:type <urn:iso:3166_1> .

and 

 _:1 rdf:type <urn:iso:3166_1> .
 _:1 rdf:value "fi" .

except that in the latter case, the literal itself is
"visible" according to generic semantics, without the
need to parse a system-specific identifier.

Sorry, still not "getting it"...

> >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?
> 
> But literals are node labels in ALL the proposals. How else could 
> they be in the graph at all?

Firstly, I missed the point that every occurrence of a literal
gets its own node. Fair enough.

The problem is that a literal is not a globally unique identifier.
So to that end, if you are using a literal as the sole identity
of a bNode, you are losing the connection between its statement
context and the value itself.

A resource is a resource is a resource no matter where it occurs
but that is not so with literals. They are contextual, and their
interpretation is specific to each occurrence (even though there
may be common intepretations applied frequentely).

If one has multiple nodes with the same URI label, one can presume
that the total knowledge defined for that resource is the union
of all such nodes. The same is *not* true of all nodes labeled
with the same literal. Right?

So, you must give each occurrence of each literal (bNode) a
unique label in the graph, so that you don't lose the context of
the statements in which those literals serve as objects, right,
and if so, then how is that anything different than the present
"genid:" or "online:" tricks used at present?

Cheers,

Patrick

Received on Tuesday, 6 November 2001 06:20:22 UTC