- From: Brian McBride <bwm@hplb.hpl.hp.com>
- Date: Thu, 28 Mar 2002 15:59:41 +0000
- To: Aaron Swartz <me@aaronsw.com>, RDF Core <w3c-rdfcore-wg@w3.org>
I took another look at this. Good stuff Aaron, and thanks again. At 13:59 22/03/2002 -0600, Aaron Swartz wrote: [...] > It is important to note that RDF language is used to transmit > meaningful information, and thus has the same legal status as > assertions, in say, English would. How about the following based on the text from F2F meeting: [[ It is important to note that the RDF/XML language is used to represent assertions. Assertions made in RDF are analogous to assertions made in any other language. The author and/or publisher of these assertions is responsible for them. It remains the responsibility of courts to determine legal responsibility considering the effects of context and other factors. ]] This suggestion is motivated by the following concerns about the original text: o which RDF language? o it is ungrammatical - the language does not have the same legal status as statement expressed in English. You wish to claim that statements expressed in RDF have. - the RDF language doesn't transmit anything; statements expressed in RDF may be transmitted o what does meaningful mean here? Applying the Williams test, what's meaningless information? Does HTML not represent meaningful information? Is RDF really any different in that regard? o I note the original text is cleverly worded; it suggests that the meaning of RDF statements would be modified by context the same way that English statements would. Hmmm, do I believe that? I have a web page with embedded PICS labels represented in RDF. The web page is entitled "A collection of false statements and a pornographic image". The PICS labels say the content is not pornographic. The page does contain a pornographic image. The title suggests that english statements on the web page are treated as unasserted. But I suggest the PICS labels are asserted and the publisher of this web page should be in trouble. This whole assertions issue is rather deep and difficult, at least for me. o The last time the WG talked about this, a number of folks were concerned about our right to 'make law'. Is this statement an attempt to 'make law' or are you saying there is existing law which makes this statement true? [...] > Optional parameters: charset > > Same as charset parameter of application/xml as specified in > [5]. Do we want to parameterize this. " as specified in [5] or the most recent specification that supercedes it." > Encoding considerations: > > Same as charset parameter of application/xml as specified in > [5]. ditto > Security considerations: > > Security considerations include many of those described in > section 10 of [5] and more, due to the semantic nature of RDF. > RDF documents may make assertions about anything, and thus RDF- > based systems want to be certain that they can trust the > document. It is expected that future work with Digital > Signature and "Web of Trust" will make it more clear how to > build secure RDF systems. If Graham and others are happy with this, then so am I. > Interoperability considerations: > > For maximum interoperability it is recommend that RDF files use > the Basic (un-abbreviated) RDF Syntax, since this is most > likely to be understood by RDF parsers and remain stable > through future RDF specifications. It is also recommended that > RDF documents do not use processing instructions, as RDF > parsers give no meaning to them. Where did this come from? Surely an RDF parser is required to parse both the abbreviated and un-abbreviated syntax. I'm not comfortable with recommending, for example, that the typed node production is not used on grounds of interoperability concerns. What is the basis for the stability argument? There is an interoperability issue over the difference between the new syntax doc and M&S, e.g. adding xml:base, removing aboutEach and aboutEach prefix. How is versioning handled in mime-types, if at all? Do we need to make it clear that this mime type is intended to refer to the current specs, not m&S. Ah, I see you do with the ref to the current syntax doc not m&s. parseType literal is another - the string is non-deterministic. > Published specification: see [1] > > Applications which use this media type: > > RDF is device-, platform-, and vendor-neutral and is supported > by a wide range of Web user agents and authoring tools. > > Additional information: > > > >Swartz Expires September 20, 2002 [Page 4] > >Internet-Draft application/rdf+xml March 2002 > > > Magic number(s): none > > Although no byte sequences can be counted on to consistently > identify RDF, RDF documents will have the sequence "http:// > www.w3.org/1999/02/22-rdf-syntax-ns#" to identify the RDF > namespace. This will usually be towards the top of the > document. They *will commonly* have. [...] > @@ some w3t person? danbri? Danbri would be good. May I suggest including DaveB as syntax editor as a joint submitter. [...] >3. Fragment Identifiers > > Section 4.1 of the URI specification [4] notes that the semantics of > a fragment identifier (part of a URI after a "#") is a property of > the data resulting from a retrieval action, and that the format and > interpretation of fragment identifiers is dependent on the media type > of the retrieval result. > > However, in RDF, the thing identified by a URI with fragment > identifier does not bear any particular relationship to the thing > identified by the URI alone. This contradicts some readings of the > URI specification [4], so caution is recommended when creating new > RDF terms which use fragment identifiers. > > The rdf:ID and rdf:about attributes can be used to define fragments > in an RDF document. Lets not beat about the bush here. Suggest replace last two paras with: The rdf:ID attribute can be used to identify a fragment in an RDF document. In RDF, a URI with a fragment identifier names a resource. The XML element with an rdf:ID attribute whose value is equal to the fragment identifier in the RDF/XML representation of the resource named by the URI is an RDF/XML representation of that resource. If the tag rules with us, this is the way it should be. Nice work. Brian
Received on Thursday, 28 March 2002 11:04:01 UTC