Re: summary of reification semantics issues (material for discussion).

At 11:29 19/03/2003 -0500, Tim Berners-Lee wrote:

[...]


>>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 .

and also

_:s foo:saidBy fred .



>>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,

because it is no longer possible to determine who said what where; the 
association between (fred and doc1) and (john and doc2) has been lost.

>  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,

I have no idea what that last phrase means.

>  by
>relating the document to a triple. Works fine as far as I can see -- and 
>useful, to boot.

If you are saying that there are other rational consistent choices the WG 
could have made, then, speaking for myself, I do not dispute that.  I 
myself, would have made a different choice.  So it seems would you.  But 
that is not the point.

I am having trouble understanding what position you are arguing for, and on 
what grounds you are making the argument.  So far your argument seems to 
consist of "I don't understand the WG's position so it must be wrong".

My first objective is to ensure that you at least understand why the WG did 
what it did.  It seems to me that would put you in a stronger position to 
disagree with it.


>>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?

Have I managed to be clearer this time?


>>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.

Again, I am confused about the nature of this implementation 
experience.  Please don't take this as being rude, but its the best way I 
can think of to explain my misunderstanding.  If I take a hammer and try to 
use it to drive a screw, I may well find this "implementation experience" 
unsatisfactory, but is that the fault of the hammer.

[...]



>>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 formal semantic constraints on its meaning are given in the semantics 
document:

   http://www.w3.org/TR/rdf-mt/#Reif

which also notes that further semantic constraints can be applied by other 
layers.  The primer provides an informal guide to its use:

   http://www.w3.org/TR/rdf-primer/#reification

You will find it used in the RDF schema for P3P:

   http://www.w3.org/TR/p3p-rdfschema/#Appendix_RDF-XML

Here partial reification is used to assert that web sites collect 
statements of a particular form, as in:

   http://www.w3.org/TR/p3p-rdfschema/#Example-2-2


>>  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?

   https://sourceforge.net/mailarchive/message.php?msg_id=2355386

is the best I can do and on its own isn't terribly compelling.  The 
sourceforge archive

   https://sourceforge.net/mailarchive/forum.php?forum_id=8988

unfortunately loses attachments :( something we didn't know at the 
time.  On the client lists there are various discussions, e.g. a bug report

   http://groups.yahoo.com/group/jena-dev/message/2105

Have a browse around and you'll get a feel for what comes up.

As an aside, experience with these other lists and archiving systems 
illustrates just what a great job the systeam do with the mailing lists and 
archives.


>>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.

This sort of statement is very hard to deal with.  What trouble?  I just 
don't know what you are trying to say.


>>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.

Again I'm not sure what that means - we are not updating M&S so how can we 
'remove' something to it - but it may be easy to meet, though in a trivial 
sense.

There are no parser conformance requirements.  We do not even define a 
notion of parser as we define no processing model.

We define a grammar, and we illustrate that grammar with test cases.  This 
is a device for augmenting the specs with specific, machine testable 
examples.  The reification syntax is part of the grammar as it was in 
M&S.  Unless we remove it, it seems sensible to provide machine checkable 
examples so that those who do support it, support it properly.  And as we 
do not define conformance, there is no basis for a notion of 'optional'; 
optional in what?

Brian

Received on Wednesday, 19 March 2003 15:01:59 UTC