- From: <Patrick.Stickler@nokia.com>
- Date: Wed, 14 Nov 2001 20:20:49 +0200
- To: Graham.Klyne@MIMEsweeper.com
- Cc: w3c-rdfcore-wg@w3.org
> 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