RE: The X Datatype Proposal

> Maybe I'm being dumb, but as far as I can tell the basis of 
> your proposal 
> is to describe *every* statement in a RDF graph by a structure using 
> subject/object/predicate properties (i.e. the structure called 
> "reification" in the original M&S document).

You're not being dumb. That's what I'm proposing, but not
as a model or view serving as the basis for notation. Notations
which take the present resource-centric view are much easier
for humans to work with.

The goal was to try to define a layer below the current graph
model which was based on the reified statement, and which
(I think) provided a simpler, more consistent basis for 
capturing the binding of type to literal as well as general
statement qualification, handling both in the same way.
  
> This means that a statement that ascribes a type to a literal 
> can do so by 
> using a subject property to reference the literal value, as 
> in (using N3):
> 
>      [ a rdf:Statement ;
>        rdf:subject "10" ;
>        rdf:property rdf:type ;
>        rdf:object  xsd:integer ]
> 
> This seems to me like a rather long-winded way around what 
> Pat is proposing 
> to allow

It is a more long winded representation, yes, but I think
an essential one to address statement qualifications such
as scope, authority, source, etc.

Again, it's not meant to be the basis for a notation such
as N3 or RDF/XML.

> (as a legitimate inference, if not in the RDF/XML 
> syntax), namely 
> literals as subjects:
> 
>      "10" rdf:type xsd:integer .

The part that is missing in the above representation
is the identity of the node for which "10" is the 
label.

The only way a triple in NTriples maintains the context 
of a literal is to make the nodeID explicit. If I understand
the point of NTriples (or triples in general) it is a way to 
distill the graph into a linear representation such that
it can be reconstructed again.

So, if we have a graph

  X ---foo---> "10" ---rdf:type---> xsd:integer

  Y ---foo---> "10" ---rdf:type---> xsd:byte

then if we express that as

   X foo "10" .
   "10" rdf:type xsd:integer .
   Y foo "10" .
   "10" rdf:type xsd:byte .

then we have ambiguity. It is not possible to
know which literal goes with which statement
or whether they are the same node or different
nodes.

Rather, we need

   X foo _:1:"10" .
   _:1 rdf:type xsd:integer .
   Y foo _:2:"10" .
   _:2 rdf:type xsd:byte .

Now, we know which node is which and can rebuild
our graph reliably.

My motivation for the X proposal notation was to try
to get below the resource-centric graph and its
relation to notations and capture the knowledge 
(statements) embodied in the graph.

Still, the X proposal is very much in line with Pat's
way of viewing nodes with literal labels as subjects 
(presuming we keep track of which node is which in
the NTriples notation).

> just seems like an order of magnitude simpler to me.

Again, it wasn't meant to be a notation, just a model,
and to that end, I think it is simpler than the current
graph model overall, once you take into account reification 
of statements.

But that's just my opinion, and I'm probably wrong ;-)

> And there are still all the issues of how to construct a 
> formal semantics 
> (preferably a model theory) for your proposal, which you 
> haven't started to 
> do.  

Nor will I, and if that is a prerequisite for consideration,
then I guess that rules it out right there.

> Finally, I think there are some aspects of your proposal that 
> would prevent 
> it from describing some aspects of legal RDF as currently 
> defined 

That may be true, though I haven't yet seen any.

> (notably 
> the distinction between subject nodes and nodes with URI 
> labels). 

Not at all. A subject node is a node which is the value of
an SNode 'subject' facet. A node with a uri label is a UNode.

The distinctions are quite explicit.

--

Again, the goal of the X proposal was to try to look at the
issue from a different perspective, from a different level
below the current resource-centric graph model. It may very
well be too radical or too informally expressed to be useful
to anyone else -- and I suggested the former in the proposal
itself.

So, I'm not really looking for the X proposal to be chosen
over the others, necessarily, but perhaps the fact that it takes
so different a view may be useful in understanding and evolving
the other proposals. Then again, maybe not...

Patrick

Received on Wednesday, 14 November 2001 13:20:44 UTC