summary so far.

Hi All,

Here's a summary..

HTTP/REST Resources [

uri space: absolute-dereferencable-URIs, GETtable URIs, URLs.

There are three core views that I can see:

1: Resource maps to a set of values over time, value at one time (the 
state) has 1:N representations.
   (IR theory 1)

2: Resource maps to a set of values over time, those values are resource 
representations or resource identifiers.
   (IR theory 2)

3: Resource maps to anything in the world, you can get representations 
which reflect the state of that resource in some way.
   (inferred theory from "you can name anything with a uri")

1,2 are IR theories, 3 is mentioned by a few people - REST says all 3 
things and potentially conflicts with itself (read section 5.2.1.1 
closely and you'll see)

Technically (not socially), only 2 is provable, because the uniform 
interface hides what's behind it. It is less a theory, and more a fact.

2 is also self definitional, in that it defines what an information 
resource is: a mapping to a set of resource representations or resource 
identifiers over time.
]

now, follow closely.. (sigh, potential brain-f*** ahead) [

Theory 2 above, is a technical fact, an HTTP/REST resource is a set of 
representations or resource identifiers over time.

We refer to HTTP/REST resources with URIs, let's say <u>.

So, <u> does not refer to an HTTP/REST resource, that is, even if you 
could see the entire set of representations ever given to every person, 
you still often cannot deduce to what the URI refers, what it names.

Here is some evidence to back up this claim:
   http://lists.w3.org/Archives/Public/public-awwsw/2011Mar/0006.html

In the case pointed to above, you must see how the URIs are /used/ 
(consistently over time) to establish what they refer to; and not what 
the information resource reflects (consistently over time).

All names can be used to refer to anything, this, is a social fact.

A distinct name, can be used to refer to different things over time, and 
the distinct things or concepts named can overlap, for example "cool" or 
"hot", this is also a social fact. It also remains true for some URIs.
]

Okay, there is nothing any of us can do about the above, so, we must 
place technical constraints where we need them, or offer technical 
solutions, in the realm of the machine, such that machines do not 
experience the same ambiguity we see above, wherever possible.

The technical issues we need to (and can) address are:

  - we need a resource description framework (check!)
a - ensure that wherever possible each URI is used to refer to one 
distinct thing
b - ensure that wherever possible we can refer to both information, and 
the thing(s) the information is about
c - ensure that wherever possible we can offer descriptions of things 
which are "on" the web (images, services, gateways and pdfs for example).
d - ensure that wherever possible the deployment of data is optimized 
for the machine and network friendly.
e - consider and take in to account the way in which humans, especially 
those non technically aware, will and do use URIs around the web and in 
data.

There are more considerations I'm sure, but I've labelled the above a-e 
to reference below.

We have a core set of different approaches already, and afaict not one 
of them covers all the needs above.

303
   covers a,b and partially e

#
   covers a,b, and partially d,e

primary topic (1 resource, 1 description) <u>/"u", tdb:, any form of pre 
or post fixing chars, or alternating syntax
   covers a,b and partially d

<u> = primary topic, content-location = IR
   partially covers a,b,d,e

209 returned for <u> = primary topic
   partially covers a,d,e (not deployed, high cost)

MGET + 209
   covers c, partially covers d (not deployed, high cost, yet efficient) 
and partially e

Link pointing to meta data about a resource
   covers a, b, c, e (not efficient at all though, worse than 303 
efficiency wise)

do nothing, only consult RDF
   partially covers a,b,d,e - easy for an individual to get right, hard 
for the world to agree on uri usage, "a mess".

We need more options, or combinations - issue-57.

Best,

Nathan

Received on Wednesday, 2 March 2011 00:05:34 UTC