- From: Frank Manola <fmanola@mitre.org>
- Date: Mon, 07 May 2001 13:07:49 -0400
- CC: rdf core <w3c-rdfcore-wg@w3.org>
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