On Sunday, Mar 16, 2003, at 15:13 US/Eastern, Brian McBride wrote:
> Tim,
>
> Reviewing the content of this thread, I believe you make the following
> points:
>
> A it is not clear to you why the WG chose the current reification
> proposal
> B cwm uses reification in a manner that is not consistent with the
> current definition
> C the current reification proposal is a barrier to adoption of RDF
> and it might be better dropped.
>
> Concerning A, the WG were considerably influenced by Ron Daniel's
> assertion that the intent of the original WG was to provide a
> mechanism to support provenance. The use case that was highly
> influential is as follows:
>
> Consider the following 2 graphs:
>
> Graph G1:
>
> _:s rdf:type rdf:Statement .
> _:s rdf:subject subj .
> _:s rdf:predicate pred .
> _:s rdf:object object .
> _:s foo:saidBy fred .
> _:s foo:saidIn doc1 .
>
> Graph G2:
>
> _:s rdf:type rdf:Statement .
> _:s rdf:subject subj .
> _:s rdf:predicate pred .
> _:s rdf:object object .
> _:s foo:saidBy john .
> _:s foo:saidIn doc2 .
>
> Merge the two graphs and then determine who said what, where. If the
> _:s nodes in each graph denote a statement (as opposed to a stating),
> it is identified by its subject predicate and object properties which
> would allow the two _:s nodes in each graph to be merged.
Yes, giving
_:s rdf:type rdf:Statement .
_:s rdf:subject subj .
_:s rdf:predicate pred .
_:s rdf:object object .
_:s foo:saidBy john .
_:s foo:saidIn doc1 .
_:s foo:saidIn doc2 .
> The WG concluded that if reified statements denoted triples, rather
> than occurrences of triples, the scenario above would lead to many
> modelling errors and further confusion.
I don't follow how they concluded that, as the example above suffers
from no confusion that I can see. The triple is stated by two files.
(Maybe I have misunderstood the way the WG uses
"statement" and "stating". I assumed a statement means the abstract
tripe, and a stating is
the fact that that triple occurs somewhere.) Here "saidIn" expressed a
stating, by
relating the document to a triple. Works fine as far as I can see --
and useful, to boot.
> I hope this example goes some way to persuading you that the WG is not
> entirely off its trolley in making the proposal that it has.
I can't say it does. Maybe we have all our terms backward or something.
or maybe I have missed
something obvious above. If there is a modeling problem, then can you
derive something ridiculous?
> Concerning B, you note the current proposal is unsuitable for the ways
> it has been used in cwm. That may be so, and therein may lie a clue
> that the representation of rules was not what it was designed for.
>
> The WG was aware of issues such as the "{ }" mechanism in cwm, the
> desire to represent graphs within graphs and the notion of contexts.
> It decided that this area was beyond the scope of its current charter
> and has recorded an issue for consideration by a future WG:
Indeed. I don't expect the group to put in {} or the equivalent at
this stage,
I was really explaining that my attempts to use reifications in the
current
style of the spec didn't work, and I abandoned it - as implementation
experience.
> http://www.w3.org/2000/03/rdf-tracking/#rdfms-contexts
>
> I fear this is not a trivial area into which to venture.
>
> You note that if the current vocabulary were defined as you would
> prefer, then new vocabulary can be defined to represent the other
> meaning. That argument is two edged. Can you not define new
> vocabulary to represent the concepts you use in cwm just as well? I
> was wondering whether you also had a solution for b-nodes as the
> objects of the reification triples.
Yes, indeed I can define another vocabulary.
> As for C, dropping reification all together. Reification does cause
> confusion and the WG did consider this option, but we do know that
> people use the current reification machinery.
Apart from test cases, do we have some axioms or some evidence of what
it is supposed to mean? Pointers?
> The note on the RDF schema for P3P for example uses it (though I
> doubt anyone uses the note) and in the jena project we know that
> people use it because not only do we get support calls, but folks
> asked for us to ensure we kept the Jena 1 optimisations supported in
> Jena 2.
optimizations? Got a pointer to the details of this? The user's email?
> The WG compromised and decided try to marginalise reification to "just
> another bit of vocabulary" as far as it can.
The trouble is, a parser is required to output it when someone puts an
ID on a statement.
And putting an ID on a statement may seem, to the uninitiated, to be a
perfectly
reasonable thing to do.
> It is not part of the concepts document and is mentioned in a low key
> way in schema. It has to be acknowledged that its special treatment
> in the syntax means that it is singled out to some extent. But then,
> various interesting alternative approaches to RDF syntax are gaining
> traction.
>
> Hopefully, careful explanation in the primer will minimise further
> confusion.
I would prefer to see it removed from parser conformance requirements
to RDF M&S - or it will become much more difficult to weed out later.
> Brian