- From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Date: Fri, 19 Oct 2001 01:31:34 +0100
- To: w3c-rdfcore-wg@w3.org
Brain: > > Thanks for calling this out Dave. I'd like to see a general policy that > > proposals that change what M&S says, or the common interpretation of what it > > says, are specifically highlighted. > > > > It would be easier to just say, we are not changing the current spec, but we > > already have precedent, aboutEachPrefix, that we will change something if we > > feel there are very strong reasons to do so. > > > > I haven't seen any such case made for this change. Dave: > I've no particular strong reason for making this change, rather than > just neatness or consistency and as issue owner, I want to get it > closed. In this case it seems like even if it was not used much, we > can keep it around in the syntax without too much trouble - solving > it with better wording and specification. > > Anyone who has a very good reason for a requirement to change this, > please can you give evidence, as Brian asks. > WARNING WARNING JEREMY IS EXPLODING ... :) I feel strongly about this. The 'common interpretation' is not defensible. The two resolutions Dave proposed are defensible. here goes .... [This concerns exclusively the interpretation of rdf:ID on propertyELt productions]. *strong reasons* 1: The current spec is self contradictory. 2: The 'common interpretation' (by a few members of this WG) of this differs from any plausible reading of the spec. 3: The current spec or the common interpretation both present considerable burden to understanding the reification rules in RDF/XML, and hence fundamentally limit the take-up of the use of reification. 4: The current spec is how it is because of an editorial oversight. This is an honest-to-goodness error, and should be corrected. 5: There are a number of cases in the mail archives of both novices and experts being confused by this issue (including DanC, and myself). 6: There is no record of any argument for it being like this. No one, who has been aware of the contradiction between: [[[ (Para 232) r2 is the resource named by the resource attribute if present or a new resource. If the ID attribute is given it is the identifier of this new resource. ]]] and: [[[ (Para 214) The value of the ID attribute, if specified, is the identifier for the resource that represents the reification of the statement. ]]] has ever articulated reasons for para 232, the best is the "backwards compatibility" argument. 7: Whenever this is discussed in any mailing list no-one actually says they use para 232; it is only a few parser writer (almost all represented in the WG) who have any legacy to be backwardly compatible about. I will, in follow up messages, expand many of these points. This is wrong. It was always a mistake. It was not the intent of M&S. It has never been implemented. There is no legacy. It is a burden to implementators. It is a burden to document writers (if any of them wish to use the facilities provided?) To remove Para 232 (by not creating text that repeats it) will be a genuine clarification that comes about as part of our task of rearticulating M&S. It will be in keeping with the intent of the previous WG much more so than the necessary clarification concerning unqualified attributes. From our charter: We should make limited [[[ fixes, clarifications and improvements to the specification of RDF's abstract model and XML syntax. ]]] and [[[ it is the responsibility of this group to not let near-term deployment considerations grossly increase the future costs (to implementors, authors, users, etc.) of new features. ]]] Introspective use of metadata requires use of reification, this was a core issue for the old WG and one they ensured was handled in the syntax. They had one or two aborted attempts at articulating reification, and by editorial accident, some text from one of these (para 232) ended up in the final spec. As it is, RDF applications to date have made less use of reification than the original WG hoped for. If we wish to continue that hope then we should clarify their intent: make reification easy, rather than leave this horrendous corner case in. This argues in favour of consistently reading rdf:ID as reification rather than disallowing it in one case for spurious historical reasons. Lance the boil. Jeremy PS: I am taking some risks in overstating my case - like asserting para 232 has never been used by a document writer in anger. Later, I will assert that para 229 has never been implemented, I might be wrong, but it will more fun if I stick my neck out.
Received on Thursday, 18 October 2001 20:26:59 UTC