reification "subagenda"

This is intended as a possible "subagenda" for the reification 
discussion at our next telecon (it is also intended to "kickoff" any 
additional email discussion people want to have on the subject before 
then).  To review status:  At the 2002-02-08 teleconference, the WG 
overwhelmingly supported the idea that support for provenance was more 
important than conformance to the current M&S reification model. 
However, as Brian noted, in trying to support provenance, we also need 
to recognize that the charter doesn't support arbitrary amounts of 
activity on this issue; we're primarily just trying to clarify RDF as it 
stands.

There are a several immediate and concrete things we can (and should) do.

1.  Brian suggests that we (explicitly) decide on answering the 
question:  Does

   <stmt1> <rdf:type> <rdf:Statement> .
   <stmt1> <rdf:subject> <subject> .
   <stmt1> <rdf:predicate> <predicate> .
   <stmt1> <rdf:object> <object> .

   <stmt2> <rdf:type> <rdf:Statement> .
   <stmt2> <rdf:subject> <subject> .
   <stmt2> <rdf:predicate> <predicate> .
   <stmt2> <rdf:object> <object> .

   <stmt1> <property> <foo> .

   entail:

   <stmt2> <property> <foo> .

[Brian suggests that the answer is NO]

2.  In another message, Brian said:  "A simple way to interpret the vote 
at Friday's telecon is that we decide that an rdf:Statement represents a 
stating (an occurence of a statement)."  I think this is something we 
should explicitly decide as well (in a manner consistent with our 
decision on #1).

NB:  If the decision that rdf:Statement represents a stating were made, 
DanBri has said:

> Such a clarification of rdf:Statement would set things up so that others
> (eg. via a Note, via later work of this WG or another, whatever) could
> provide further properties that better describe the characteristics of an
> rdf:Statement. For example, DanC and I might define util:predicateURI,
> util:subjectURI, util:ObjectURI, each having rdfs:domain of rdf:Statement,
> to address the concerns aired in the use/mention/superman thread. By
> agreeing that rdf:Statement's members aren't individuated by p/s/o, we'd
> lay the groundwork for future improvements to reification.
> 

3.  Brian also suggests that we decide on Graham's entailment:  Does

<ex:subj> <ex:prop> <ex:obj> .

entail

      _:r <rdf:type> <rdf:Statement> .
      _:r <rdf:subject> <ex:subj> .
      _:r <rdf:predicate> <ex:prop> .
      _:r <rdf:object> <ex:obj> .

[Brian suggests (I think) that the answer is NO.]

4.  If decisions are made about #1-#3, one of the issues we then need to 
decide is whether we need (or can) do anything else to support 
provenance in RDF 1.0.  It seems to me that fully dealing with 
provenance may require addressing the following:

a. being able to actually identify the specific triple (the "literal" 
triple;  what the guy actually said, including the literal URIs), as 
opposed to a *description* of that triple.

b. (suggested by Pat) being able to distinguish the triple itself, the 
proposition expressed by the triple, and possibly the assertion that the 
proposition or triple is true (e.g., what things do we want to be able 
to express the provenance of).

c. (a pragmatic issue, partially independent of (a) and (b)) working out 
some use cases illustrating how we suggest provenance be handled in RDF, 
given our new understanding / interpretation of reification, that we can 
use in specs (e.g., a new "Ralph Swick" example).

I'm not necessarily suggesting that we need to specifically provide 
solutions to all of these, but rather throwing them out as possibly 
helping scope the problem.  For example, we may not want, as part of our 
current activity, to provide distinct syntax for all the variants in 
(b).  However, we might decide after looking at them that we can outline 
a path that a later group could pursue to make those distinctions.

--Frank



-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875

Received on Wednesday, 13 February 2002 17:10:50 UTC