RE: The FragId issue

Graham, thanks for your reply, my comments follow inline.

> >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"
>
> Yes... and I think that needs be asserted normatively somewhere ... I think
> the application/rdf+xml MIME type registration is that place.
>
> >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).
>
> I think the essential normative information is provided by the formal
> semantics.  The purpose of this section was to show how the formal
> semantics is consistent with other uses of fragment identifiers.
>
> I'm not sure whether this is or is not normative;  I don't know of another,
> contrary, view that is consistent with the formal semantics of RDF and
> which would fail to interoperate with the view expressed here.
There's a use case below which can clarify my doubts here (essentially, I don't know whether and how this mandates the MIME type of
a resource to be application/rdf+xml).

>
> But I think it's correct, so I'll respond as if it is normative...
>
> >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.
>
> I don't have a formal meaning for "indicate a Web resource with an RDF
> representation", though I thought the intent was clear enough.  Maybe I
> should say "identify a Web resource with an RDF representation", or even
> just "Identify a web resource, which is presumed to have an RDF
> representation".  (I'll assert that *any* resource has an arbitrary number
> of RDF representations, so this doesn't create any new constraints.)

Okay, I see, thanks for the clarification. The confusion I had here lies in what the word "presumed" stays for. As you say it, it
looks like a very weak "presume", i.e.,
a) it is not an rfc2119 SHOULD, and
b) it's generally unspecified the way you actually retrieve the "presumed" RDF representation of a resource

Correct?

>
> The point about URIs not necessarily being dereferencable as RDF is
> explicitly addressed:
> [[
> eg:someurl#frag means the thing that is indicated, according to the rules
> of the application/rdf+xml MIME content-type as a "fragment" or "view" of
> the RDF document at eg:someurl. If the document does not exist, or cannot
> be retrieved, then exactly what that view may be is somewhat undetermined,
> but that does not prevent use of RDF to say things about it.
> ]]

I'm a bit confused, so let me give a use case:
you use in RDF http//www.example.com/foo.xml#minnie
You can actually retrieve it, but it's an XML (not RDF) file (so, not with application/rdf+xml).
So, does this clash with the proposed fragid view?
Note this is related to point b) above (if the answer to b is yes, then I think the above usage is fine, and maybe I see what you
wanted to say :).

>
> Can you explain if this does not address the concern you raise?
>
> >ps On normativeness, the same issue would apply to Section 4 as well
> >(Meaning of RDF), but that would be on a different scale: [...]
>
> This is being dealt with under the heading of social meaning, so I'll
> assume I can let this matter be handled there.
Yes, that's very reasonable ;)

Ciao,
-M

Received on Friday, 28 February 2003 19:33:18 UTC