Re: Issue rdfms-not-id-and-resource-attr

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