Re: Issue http://www.w3.org/2000/03/rdf-tracking/#mime-types-for-rdf-docs

Referencing the "context in which it [top level RDF] occurs" may avoid
the issue of having to assign provenance when it isn't known, but I
think we need to say more clearly how provenance is assigned when it
*is* known.  For example, we need a precise definition of "context", in
the sense of this container of top-level RDF.  As far as assigning
provenance is concerned, all we have now (I think), is the "Ralph Swick"
example, in which you reify the statement, and then make statements
about it.  This doesn't illustrate assigning provenance to "top level
RDF" (or if it's supposed to it's not clear about it).  However, one way
of reading the beginning of Section 4 of the M&S is that the reason for
reification is to turn a statement into a resource, since you can only
make statements about resources.  If a collection of RDF statements is
*already* a resource (has a URI), then you can make statements about the
collection without physically reifying the statements.  On this reading,
if the author of a Web page (in HTML) has also embedded some RDF to
describe the contents, the author could (for example) also include some
RDF "about" that page identifying herself as the author, using the
page's URL to identify it.  The PICS example (section 7.6) in the M&S
shows another way to do this.  I repeat:  I think all this needs to be
defined in the M&S, not in definitions of MIME types (as important as
these may be).   

A couple of related points regarding PICS:

1.  Appendix B makes it clear that descriptions of a resource may be
located separately from the resource they describe, and retrieved from
that separate source.  It is important that the provenance mechanism be
able to correctly distinguish between who really made the assertions,
and where they happen to be coming from (e.g., the "service bureau"), if
the alterative mechanisms described at the top of Appendix B are going
to be semantically equivalent.

2.  The provenance mechanism must deal not only with who made the
assertions, but other descriptive attributes like the time they were
made.  Again, the mechanism must correctly distinguish between when the
assertions were originally made, and when they happen to be sent on this
particular access. 

--Frank

Graham Klyne wrote:
> 
> At 09:40 AM 5/3/01 +0100, Brian McBride wrote:
> >The points that Frank has raised are substantive; I'm not sure that the
> >rdfms-assertion issue is going to be easy to deal with.  For example, you say
> >that the 'sender' is asserting any RDF statements 'sent' to be true.  Who
> >is the
> >sender, e.g. in the case of RDF embedded in your home page?  Your isp?  When
> >this issue was raised at the rdf-interest f2f, there was a suggestion that
> >such
> >assertions should have consequences in law, e.g. if they are libelous -
> >how does
> >one determine exactly what has been said in a way that will work in court?
> >These are deep waters.  What do you think of following Frank's suggestion and
> >separating the mime-type issue from the assertion issue?
> 
> There has been some suggestion that:
> 
> "top-level" RDF statements are asserted in the context in which they
> appear, and that reification, rather than being a mechanism for quoting,
> might be viewed as a syntactic device for nesting RDF statements in other
> RDF statements.  The effect is close to the current situation, but might
> help to resolve some of the semantic issues that have been raised.  The
> reference to "context in which it occurs" avoids the issue of having to
> assign provenance when it isn't known.
> 

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

Received on Monday, 7 May 2001 13:08:46 UTC