Latest views

Two Views, I recently wrote up after this chain of mails. This would be 
the most current things (of mine) to give feedback on.

in the below "bound to" and "associated with" are weak, interchangeable, 
terms.

1
[
So, here's a simple-ish summary of the problem - disclaimer, all IMHO of 
course:

Outline:
     each URI <u> is bound to a thing T by a set of agents SA (this is 
the naming process)
     <u> refers to T

     some URIs are bound to a set of representations SR over time by the 
dereferencing process (i.e. GET a URI)
     <u> refers to T, SR

Let's assign the name XT to this class of URIs which are bound to both a 
T and an SR. (things which name something, and which you can GET 
content+meta by dereferencing)

Where T == SR this forms a subclass of XT which we'll call YT (just 
means that the URI is used to refer to the thing you GET, like a web 
page or an image)

The opposing views:
   for all <u> in XT, T == SR
   (all members XT are members of YT, doesn't account for T != SR - this 
is an information resource theory)

   SR is bound to T not <u>
   (means T == SR && T != SR - this is the content+meta gives 
information about the thing theory, slash uris name anything)

   <u> is bound to T, and T != SR
   (SR is unbound to any name, or bound to "some other name" - this is 
the <u> :retrieved_from "u" approach, or content-location = graph uri)

   <u> is bound to SR, and T != SR
   (T is unbound to any name, or bound to "some other name" - can't see 
what it equates to but it's a theory)

   <u> is bound to T, SR and T != SR
   (can't use deref URIs as names - URI collision, or the chimera 
theory, this is where information about <u> consists of info about both 
the information and the real world thing named. Practically it's the 
same as view 2)

Summary:
View 1, is the httpRange-14 solution (accounting for view 3 with the 303 
solution too). View 2 is implied by the REST dissertation (actually so 
is 1 and 3..). View 3 is the "we don't normally talk about the document" 
view. All of them have issues for somebody.
]

2 [
Here's an even simpler way of looking at this..

a URI is associated with a thing by a group of agents/people as a name 
for that thing.
some URIs are also associated with a set of representations over time by 
the dereferencing process.
Why were the representations made available for that URI?

- because somebody made a web page /and then/ needed a uri to refer to it.

- because somebody named something with a uri /and then/ wanted to 
provide information about it.

- because somebody made a web page about one specific thing /and then/ 
needed a uri to refer to it /and then/ the uri became commonly used to 
refer to the thing named.

That's a really minimal set of the different ways of looking at it, 
without getting in to any technical details at all, all three are really 
common cases of how people use URIs, the in-fighting is just people 
who've picked one of the three as being gospel, or technically required 
to make things work.

It's a social problem.

The httpRange-14 resolution picked the first of the above reasons as 
being the norm, and as requiring the least technical trade-offs. The 
resolution also accounted for the second case, with precedence given to 
the importance of having distinct names, rather than network performance 
or ease of implementation, again simply a design trade-off, one which 
prioritizes humans over machines.
]

Received on Friday, 4 March 2011 20:19:32 UTC