Ian Davis wrote:
> On Thursday, May 20, 2010, Nathan <
nat...@webr3.org> wrote:
>> Can somebody give me a solid reason why I (or we) shouldn't use fragment URIs for essentially everything that can't be saved on a filesystem, or point to an issue that would be caused by using them.
>>
>
> Fragment identifier interpretation belongs to the client and is
> dependant on the media type of the response. See
>
http://blog.iandavis.com/2007/11/fragmentation for more of my thoughts
> on that.
>
> Also, in the world of web applications the fragment is now being used
> for storage of client side state, to be read by javascript on the
> client (eg gmail, google code etc). Its original use as a simple
> identifier of a part of an html document is being superceded.
As if to justify the thoughts on your blog post, your final comment on
the matter was "I wonder what URI we ought to use to refer to issue 81
on the RFC2616bis work?
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i81 is the URI
of the HTML fragment describing it. According to the webarch I can�t use
that URI to also denote the issue itself."
Before wading in to this one, I thought I'd seek the advise of those who
are more experienced in the colliding worlds of HTML Documents and RDF
Concepts under the banner of RDFa - one of the most clarifying responses
I received was as follows:
<quote>
Sometimes people ask: "Can you have an @id and @about have the same
value?" and the answer to that is yes, you can do this:
<div id="me" about="#me">...</div>
So, when that URL is dereferenced, the HTML document displays what is,
hopefully, also machine readable. However, they do NOT point to the same
/thing/. One is a resource (@about), and one is an anchor in the
representation of the resource (@id)... it just so happens that they
have the same URL.
The meaning of that URL is different based on whether you ask what the
URL identifies in the context of the semantic web, or you ask what that
URL identifies in the context of the document-based web.
URLs are ambiguous without a solid context. The requested and returned
MIMEType gives context, HTTP Headers give context, the configuration of
the User Agent gives context, time gives context... there are many
things that give context to a URL.
</end-quote>
For me this brought clarity to the issue, with HTML the code we write
and see is parsed in to a DOM and rendered as visual boxes of content,
which may or may not have identifiers, and just as an @id (or previously
@name) allowed a client to navigate between parts of the rendered DOM,
so the javascript uses of @id today provide a reference to parts of the
DOM which we can use to store state and suchlike as you note. But this
is *very* context specific.
To illustrate I can easily write a simple javascript that goes through
every element in the DOM and gives it a random @id on the fly, and
changes them every 2 seconds, is that hundreds of new URIs being minted
randomly? To me it is clear that the answer is no - it's simply a
script, working on a temporary short lived DOM within a client on a
computer somewhere, here for a moment and gone the next, equating to the
pointer of an object in memory when a program is running.
In the RDF world URIs clearly point to Concepts, regardless of whether a
description of that conceptual mapping can be dereferenced, and as we
know the concept pointed to, in all cases, is not serialization
specific. We can describe the same thing, with the same URI, in n3,
rdf/xml or many other serializations. RDFa is just another
serialization, although this time the serialization specific syntax of
the RDF is merged in with the serialization specific syntax of an HTML DOM.
To illustrate, let's say
http://example.org/jim#me identifies a Person
"jim", and dereferences to a .n3 serialization of RDF describing "jim".
If I dereference that URI with an RDF Parser like ARC, then does
http://example.org/jim#me suddenly identify the temporary in memory
'triple'? in one context it does. If I then run a little script which
swaps the value in memory to
http://example.org/frank has it just minted
another URI, re-identified jim, turned jim in to frank, changed the
conceptual mapping? Again, it is clear to me the answer is no.
Returning to your original question on that post:
"I wonder what URI we ought to use to refer to issue 81 on the
RFC2616bis work?
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i81 is the URI
of the HTML fragment describing it. According to the webarch I can�t use
that URI to also denote the issue itself."
Your question conflates and confuses many, removes context and does
nobody any good.
As far as we know a URI for that Issue 81 has not been minted
a URI has however been minted for an HTML Document which you'll find if
you dereference
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/
If you dereference the URI you question
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i81 with a
modern browser, then it'll GET the minted URI for the HTML document
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/ - hopefully the
browser will create a DOM in memory, render that DOM on screen, give a
specific element a node @id of 'i81' if it's contained by the HTML
syntax in the document, and then adjusted the positioning of the
rendered DOM to position that node on screen where you can see it - but
only in this very specific context, on a client which implements the
aforementioned functionality.
If you dereference
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i81 with CURL,
then to what does the URI refer?
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i81 may be the
identifier of some Concept, maybe even that 'issue 81', but without a
description we simply do not know, and thus as far as we are concerned
it identifies nothing, or at the least 'something unknown to us'.
By removing the context you create a grey area, something which leads to
massive amounts of time being wasted, causes confusion and delay, risks
creating splits in a fragile and very important community, and far more
importantly it slows the path adoption and puts off many would be
adopters - shameful.
Regards,
Nathan