Re: summary so far.

I will do my usual thing of rephrasing using modes of expression that
I prefer...

On Tue, Mar 1, 2011 at 7:03 PM, Nathan <nathan@webr3.org> wrote:
> 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)

There is an ambiguity in REST as to whether resources with distinct
values at time t can be in the same state at time t. (I discussed this
with Alan R a long time ago.) If so then the values depend on both the
state and the resource, not just the state.

Basically REST is a design approach that says that any change in the
valueset has to be due to some change in the resource's state. This is
impossible to falsify since any putative counterexample can be denied
just by saying we were wrong about what the state was. Nothing to say
to that since an outside observer is never privy to the state.

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

Theory 1 implies theory 2; it's just theory 2 plus the state hypothesis.

> 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")

Not sure what you mean by "maps to".  I would have said the resource
(the one that someone is using the URI as a name for) *is* anything in
the world.  Or out of it even.  And you get information about the
resource itself, not just its state.

> 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)

The paper is screwed up and we know it. When Roy says a resource is a
mapping etc., the proper expression of the idea is that his resource
theory *can be modeled* by taking resources to be functions etc.  He
can't really believe that these things are functions. There is no
evidence that he even cares about ontology. Always remember that this
is a software architecture, not a logic.

> 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.

But we know that resource isn't necessarily the same as the one that
someone is using the URI to name...

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

Some of us do, some don't.

> 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.

umm. doesn't compute. Oh, I see, you're saying the mapping from URI to
IR isn't functional. Agree completely - someone has got to (or has the
privilege to) decide which of those IRs the URI is to refer to, even
assuming that they're using the URI to name an IR at that URI. THis is
why my 'is bound to' relation is not functional.

> 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).

Yes, meaning of a URI is how it's used by agents

> 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.
> ]

Avoid the word "concept" around me... http://philpapers.org/rec/SMIBCO

> 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.

This seems like a good list. How about ease of deployment, and performance?

> 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

Can cover case c as well given a suitable relation (307 expressed in RDF).

> #
>  covers a,b, and partially d,e

Ditto

> 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

You know there are two very distinct situations here. There is the
primary topic, which is independent of URI, and then there is the
thing that is named by a given URI within a particular document. (I
don't have a nice way to say this.) They are orthogonal - the primary
topic might be a different thing from the one with named by the given
URI. (If you can figure out what it is at all.)

The primary topic method would be more likely where the document is
prose, while the URI-in-document method would be more likely where the
document is RDF.  But either works in either context.

I would like to add to our ontology, at some point, a way to do
URI-meaning-according-to-document, which is also very similar to
what's needed to give the webarch interpretation of #. The problem is
that it's a three-place relation (IR, URI, whatURImightmean), always
an annoyance in RDF. Oh yes and it's not functional - for a given IR
and URI, there might be many ways to interpret that URI consistently
with what the document says (e.g. if it's unconstrained). So this is
also semantically a tarpit.

> <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.

My current favorite is /.well-known/host-meta. Eran H. tells me he's
updated the host-meta draft and will submit it to IESG. Combine it
with a Link: header indicating that the host-meta exists and should be
consulted, and number of round trips is almost the same as for MGET or
209.

>
> Best,
>
> Nathan
>

Received on Wednesday, 2 March 2011 01:24:13 UTC