W3C home > Mailing lists > Public > public-awwsw@w3.org > March 2011

Re: Diagram of it all

From: Nathan <nathan@webr3.org>
Date: Sat, 05 Mar 2011 15:56:08 +0000
Message-ID: <4D725D18.8080103@webr3.org>
To: Jonathan Rees <jar@creativecommons.org>
CC: Pat Hayes <phayes@ihmc.us>, AWWSW TF <public-awwsw@w3.org>, David Booth <david@dbooth.org>
Jonathan Rees wrote:
> On Fri, Mar 4, 2011 at 9:54 PM, Pat Hayes <phayes@ihmc.us> wrote:
>> On Mar 4, 2011, at 7:52 PM, Jonathan Rees wrote:
>>
>>> Did you spot the contradiction, in one of your diagrams, to my axioms?
>>> In my little world, if a resource has only one representation, then
>>> much of what you say about the representation has to also be true of
>>> the resource - for example, whether its content contains the letter
>>> 'x'.
>> Hmmm. I confess to not being entirely uptodate with your axioms, but this sounds like it would rule out a lot more than just RDF graphs.
> 
> Yes, I'm very sorry, I sent that message in error. It was wrong. I
> wasted a bit of your time and lost credibility. Mea culpa.
> 
> A simple IR, one that has only one 'representation', would be subject
> to what I said, but a graph is not one of those since it has many of
> 'representations'.
> 
> Your suggestion, that a property shared by all serializations of a
> graph is their being a serialization of a graph, is technically
> correct, but what I'm looking for is something *informative* - that
> is, something that will distinguish serializations of graph A from
> serializations of graph B.  That itself is such a property, and I list
> this in the latest version of the document, so *that* would be the
> contradiction between the axioms and the idea that a g-snap is an IR
> with its serializations as 'readings' (since a g-snap is not a
> serialization of any graph, not even itself).

Jonathan,

The property is the URI, the only difference between a "representation" 
and a "resource representation", or, a "representation" and a 
"simple-IR", is that the latter in both cases is "bound to"/"associated 
with" a URI via the act of dereferencing.

Remember, the top two boxes on the diagrams are hidden behind the 
uniform interface, the top left one is just a human name for something, 
and the top right one is a name for part of a story for a particular use 
case.

Information Resource is self definitional, it's a bunch of 
(content+meta)s associated with a URI over time, when somebody sticks a 
name in the top left box which is a human name for that bunch of 
(content+meta)s over time (or something which juggles them, generates 
them, stores them, whatever) then there's no problem (e.g. named graph, 
web page, document, image of a toucan, moby dick the novel, info about 
jim), and when somebody stick a name in the top left box that /isn't/ a 
human name for that bunch of (content+meta)s over time (toucan, car, the 
moon, bob) then <u> is being used to refer to two distinct things and 
some technical tricky is needed to associate the bunch of 
(content+meta)s with a different URI which is recognised as referring to 
them.

The top right box is a name for part of a story for a particular use 
case. To illustrate, possibly the most broadly labelled and inclusive 
label we can put on that top right hand side box is "state" - so let's 
focus on this in the g-* case:

  g-box -- g-snap
    |        |
    |        |
   <u>  -- g-text

story:
<u> names a g-box, a box which contains different statements over time
the statements in that box at a specific instant is it's state, a 
g-snap, a mathematical set of triples
this state can be realized in a set of one or more g-texts 
(content+meta)s which you can GET
the GET (dereferencing process) associates those g-texts with the box 
name <u>

that's a complete story which links from <u> right around the four 
boxes, over time, through the abstract in to the realizations and back 
to <u>.

g-box is just a name for something which can juggle/store/manage a bunch 
of values over time that can be transferred as (or indeed are) 
content+meta's, associate both things with a URI and we've got our IR. 
The g-snap bit is part of a story which makes it work in this RDF use case.

The same thing goes with http and it's view of:

resource -- state
    |          |
    |          |
   <u> -- resource representation

swap to:

web page -- who cares
    |          |
    |          |
   <u> --     html

and it still works

swap to

donkey -- who cares
    |          |
    |          |
   <u> --     html

and we've got a naming collision, <u> links to two things that aren't 
recognised as being roughly the same, or in the same class.

I know it's far from axioms and technical terminology, but to me at 
least it makes sense.

reminder: the property you're looking for above, is the URI.

Best,

Nathan
Received on Saturday, 5 March 2011 15:58:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 5 March 2011 15:58:29 GMT