Re: the state of ldp-patch, and a procedural proposal

hello kingsley.

On 2013-10-03 11:40 , "Kingsley Idehen" <kidehen@openlinksw.com> wrote:
>A URI denotes an Entity. That's it.

i'd say it identifies a resource, but i guess that's just a different
preference for terminology.

>There are many kinds of Entities, perceptible across a variety of media.
>The beauty of HTTP URIs that leverage the fragment ID is that they
>enable you denote any kind of entity without introducing ambiguity,
>while also delivering many other HTTP virtues on a platter.
><#this> denotes a Post .
><> denotes a Document.

that may be the case for some resources that you control, because you
choose to support this interpretation. for other resources (such as web
pages), ...#this might very well reference the <p id="this"> paragraph in
that page. you cannot define how fragment identifiers generally work,
because they depend on the resource owner, not on your interpretation of
what they may mean. "The semantics of a fragment identifier are defined by
the set of representations that might result from a retrieval action on
the primary resource. The fragment's format and resolution is therefore
dependent on the media type retrieved representation, even though such a
retrieval is only performed if the URI is dereferenced." (RFC 3986)

personally, i never really liked that part of web architecture very much,
because it means that if you do things such as content negotiation, it is
your responsibility to make sure that fragment identifiers work
consistently across supported media types. which is doable, but just feels
a bit strange. i think there's a lot of history to why this is how it is,
and starting from scratch this part of web architecture could be designed
a little bit better now, but that's mostly an interesting thought
experiment. the main point to keep in mind is: fragment identifier
semantics are not defined by URIs or URI schemes, they are defined by
media types.

cheers,

dret.

Received on Thursday, 3 October 2013 18:57:44 UTC