The FragId issue

Another issue for consideration.

Issue FragID's:
Section 7 in the RDF Concepts doc would seem to imply that
"any RDF URI reference consisting of an absolute URI and a fragment identifier identifies the same thing as the fragment identifier
does in an application/rdf+xml"

First point (normativeness): it's unclear in the whole section whether there are actually normative statements (there are no "must",
"should", "may" or so, but wordings like "consider", "assume" etc). This makes hard to understand what real statements are mandated,
and what is just normal discourse (and as such, with no normative power).
Second point (indication): in any case, assuming normativity, this would seem to mandate that any URI present in RDF has to
"indicates a Web resource with an RDF representation". I would be very unhappy with this mandate, as URIs don't necessarily have to
be dereferenceable (it's not all URLs....), and in any case, they shouldn't be required to have an RDF representation (think of an
image).
And to further clarify, what does it formally mean for a URI to "indicate a Web resource with an RDF representation"? Some
clarification is needed...

Note that obviously the second point is moot if the answer to the first point is: no normative statements.

Thanks much,
-M

ps On normativeness, the same issue would apply to Section 4 as well (Meaning of RDF), but that would be on a different scale:
because as far as I could see, leaving it there doesn't do much harm: i.e., even if the normative aspect is not clear, and I'd
prefer Section 4 to be entirely moved to an Appendix (or deleted), leaving it there doesn't cause much troubles, because it doesn't
really enforce anything (does it?).
But anyway, the suggestion of moving it to an Appendix (or at least taking out the "normative" in the title) stands ;) If not, maybe
there should be some concern that to some people this section normatively mandates something, but to othere, it doesn't (err, do I
look too picky here? ;)

Received on Friday, 21 February 2003 15:10:59 UTC