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

Re: Graphs and Being and Time

From: Nathan <nathan@webr3.org>
Date: Tue, 01 Mar 2011 20:07:09 +0000
Message-ID: <4D6D51ED.3070006@webr3.org>
To: David Wood <david.wood@talis.com>
CC: RDF WG <public-rdf-wg@w3.org>
David Wood wrote:
> On Mar 1, 2011, at 14:06, Nathan wrote:
>> David Wood wrote:
>>> On Mar 1, 2011, at 05:32, Nathan wrote:
>>>> Nathan wrote:
>>>>> David Wood wrote:
>>>>>> On Feb 24, 2011, at 13:12, Pat Hayes wrote:
>>>>>>> It is much simpler: it is just wanting the WG to acknowledge that "an RDF graph" can either be a mathematical set, or it can be some kind of document or data structure or file than can be transmitted over a computer network. But it can't be both.
>>>>>> What is the difference between an "RDF graph" and a RESTful "resource"?  What is the difference between an "RDF graph token" and a RESTful "representation"?
>>>>> REST maps a resource to a set of values over time, each single value has a 1:N relationship with representations, "RDF Graph" (the mathematical set, platonic abstraction, g-snap) equates to a single value, and "RDF Graph Token" equates to a representation of that single value.
>>>> REST maps a resource to a set of values over time, each single value is a representation, representation equates to "RDF Graph Token" (a chunk of rdf/xml or turtle, a g-text in Sandro's mail).
>>>> The g-snap, or abstract graph, isn't a concept which relates to any REST concept, rather it is something specific to our RDF use-cases, in that we have a platonic abstraction, a mathematical set of triples, which we juggle different realizations of (from in memory structures through to serializations and so forth).
>>>> So, to re-answer your question, "RDF Graph" is a term we've used to refer to both the abstract set of triples, and the realizations of. The only thing which equates anywhere near a "RESTful resource" in our communities are "Named Graphs" and of course linked data which uses RESTful resources, we GET <u> to retrieve a realization of an abstract set of triples, to get some RDF in some format.
>>> Pardon me for saying so, but that doesn't make sense to me.
>>> A RESTful resource may be anything:  "the intended *conceptual* target of a hypertext reference" was one way Roy Fielding put it (emphasis mine).  There is no reason I can see that an abstract, mathematical concept cannot be a RESTful resource.
>> I don't really want to drag this subject up on this list, unless the chairs / team contacts think it's worth it. So I'll merely point to a discussion on this:
>>  http://lists.w3.org/Archives/Public/public-awwsw/2011Mar/0002.html
>> do also see the replies which clarifies the two world views of IRs, and the third world view of no IRs just anythings.
> OK, I'll let it go.  Perhaps we can find some time at the ftf to discuss this in person.  I still disagree, even having read the thread.

indeed, it's an interesting topic, I've held all three world views and 
fought each one to death and back - ultimately two of them are differing 
social stances but complimentary and amount to the same other than 
technical nits.

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 conflicts with itself.

At the end of the day, only 2 is technically provable, since the uniform 
interface hides what's behind it (if there is a thing with a state, you 
can't tell!) all you GET are representations.

Happy to discuss this any time, private or public - public is difficult 
because of the 8 years of social stances by different people, noisy topic!


Received on Tuesday, 1 March 2011 20:09:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:03 UTC