Re: ACTION-434: Some notes on organizing discussion on WebApps architecture

Noah Mendelsohn wrote:
> On 10/14/2010 7:06 PM, ashok malhotra wrote:
>> But, a picky point, if you add a fragId to a URL is it the same URL?  I
>> think we need to argue that it is.
> 
> If you're saying "we should advocate the position that they are the 
> same", I strongly disagree.
> 
> http://example.org/somedocument
> 
> and
> 
> http://example.org/somedocument#a
> 
> are different URIs.  See RFC 3986, and in particular the section on 
> comparison [1].  I see nothing there to suggest that the two examples 
> above are in general the same;  on the contrary, almost all of Web 
> architecture and a fair amount of deployed infrastructure for the 
> Semantic Web depends on their being different (or at least not presumed 
> the same).
> 
> Noah
> 
> [1] http://www.apps.ietf.org/rfc/rfc3986.html#sec-6

This is a very interesting area, and I hope you don't mind me adding a 
few comments.

It is often the case that fragments identify different things in 
different contexts, for instance I can serialize a description of 
http://example.org/somedocument#a in say an RDFa document which is made 
available at the URI http://example.org/somedocument - when that 
document is pulled in to a browser then in one context the URI 
http://example.org/somedocument#a identifies whatever the RDF 
description says it identifies, it is a name for something, however in 
an entirely different context (but still within the browser) the 
fragment part #a can be a pointer to a certain area of the screen, it 
can reference a temporary and often changing variable in short lived 
memory, and a whole host of other things.

A thought I often find interesting, is that if I create a simple 
javascript to add hundreds of @id attributes to the document, and to 
cycle and change them every few seconds, then each of those is an 
accessible to the client URI, and identifies something, an area of the 
screen, something in memory, but have I just minted hundreds of new "URIs"?

To me at least, the answer is a clear no, these are not "URIs" as in 
web-names, they are nothing more than pointers to short lived 
unknown-to-the-web in-memory resources, it just so happens that they can 
be displayed as a URI within a browser.

That said, the epic-win (imho) is that any of those temporary 
unknown-to-the-web URIs /can/ be used as a name and made known to the 
web, and then used at a later date to show an application in a certain 
state or for whatever else, likewise the same now-shared URI can be 
described and understood by semantic web clients as with any other URI.

However, there are many applications which use fragments as less of a 
name and more as a way to serialize variables, they have no awareness of 
  the rest of the URI, or even that it is a URI, and use the fragment as 
little more than a way of a user selecting a state / bit of data known 
only to that application (and often at only that time).

So, I'd suggest that there are two cases here, one is a 
not-known-to-the-web URI which often identifies different unnamed-things 
(in a client, at runtime only), and the second is a URI as we commonly 
know it, which /can/ identify a certain resource (application) state and 
be a web-name for that state, and likewise can be described and 
understood by multiple different applications.

Just some thoughts,

Best,

Nathan

Received on Friday, 15 October 2010 18:50:58 UTC