Re: graphs and documents Re: [ALL] agenda telecon 14 Dec

On 14 Dec 2011, at 16:08, David Wood wrote:
> Tim lost me when he said that a document returned from a URI resolution does not equal a RESTful Representation.

“document” is a term that's even more overloaded than “graph”.

In Tim's usage, the homepage of the New York Times is a document. Note that the words in the document are different every day – it's a highly mutable and ever-changing document.

In Tim's usage, the concrete HTML string that's returned when you resolve http://www.nytimes.com/ is *not* a document. He uses the REST term for that: “representation”. This is where he lost you, Dave. In Tim's usage, saying that you “return a document from a URI resolution” makes no sense. That would be like sending a telephone through a wire.

Tim's notion of “document” seems to be mostly compatible with our notion of “g-box” or graph container, except that he doesn't think of it as containing a graph – he thinks of it as yielding a representation when prodded, and the representation can then be parsed to yield a graph. He calls this “prod-and-parse” relationship “log:semantics”. In that view, obviously only things that are resolvable can have a log:semantics, while in our g-box view, even non-resolvable g-boxes can contain graphs.

> Also, we have continued confusion in this thread about what a "graph" is - see my earlier objection to the continuing use of the term RDF Graph for a g-snap.

In this particular thread I saw confusion about the words “document” and “denote”, and confusion about the compounds “graph resource” and “graph contents”. I did not see any confusion about the word “graph”.

Best,
Richard



> 
> Regards,
> Dave
> 
> 
> 
> 
> On Dec 13, 2011, at 22:59, Tim Berners-Lee wrote:
> 
>> I'm afraid I must correct this.
>> Apologies to those who have heard my definitions many times.
>> 
>> On 2011-12 -13, at 20:36, Pat Hayes wrote:
>> 
>>> 
>>> On Dec 13, 2011, at 5:29 PM, David Wood wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> I had a lengthy conversation with TimBL about named graphs at the LEDP Workshop [1] last week.  Briefly, he feels that the semantics for named graphs should work like this:
>>>> 
>>>> - An RDF Graph is named via a URI.
>>> 
>>> OK so far...
>> 
>> Well, actually the URI denotes a document, but there is a 1:1 relationship (log:semantics)
>> mostly between documents and graphs here.
>> 
>> The same URIs can be used I think in SPARQL after the "GRAPH" keyword
>> because the GRAPH keyword uses the document's URI to
>> indicate which graph.
>> 
>> In my language,  (1 2) is a list,  { ex:s ex:p ex:o }  is a graph, "foo bar" is a string, and 3.14159 is
>> a number and I don't  say that URIs formally denote any of those immutable data values.
>> 
>> You can say
>> 
>> 	 ex:pi  =  3.145926                  
>> 
>> which means that whatever ex:pi denotes it is equal to 3.145926.
>> (Now, for systems which understand =, this means they can use ex:pi
>> most places instead of  3.145926 in mathematical formuale
>> and so in fact can treat ex:pi as denoting 3.1415926,
>> even though in the basic RDF graph language, ex:pi doesn't denote
>> 3.1415926.)
>> 
>> and you can say 
>> 
>> 	<#g1> =  {  ex:s ex:p ex:o }
>> 
>> which you can read loosely as "in this document we use local symbol
>> g1 to denote [something which is equal to] the graph {  ex:s ex:p ex:o }.
>> 
>> I would NOT say
>> 
>> 	<> =  {  ex:s ex:p ex:o }                                       X NO
>> 
>> because <> is this document and  {  ex:s ex:p ex:o } is a graph,
>> nor would I say 
>> 
>> 	<http://www.w3.org/2011/12/13-foo.n3> =  {  ex:s ex:p ex:o } .           X NO
>> 
>> I would say
>> 
>> 	<http://www.w3.org/2011/12/13-foo.n3> log:semantics {  ex:s ex:p ex:o } .  
>> 
>> where log:semantics is the relationship between a document
>> and the n3 graph whose meaning is the meaning of the document
>> and which on a good day you can get by looking up the document
>> on the web and parsing which you get back. 
>> 
>> 
>>> 
>>>> - The URI denotes the RESTful Representation that is returned when the URI is resolved.
>> 
>> No it doesn't, it denotes the document. 
>> 
>>>> 
>>>> That is, the URI denotes the graph's contents, not the graph Resource itself.
>> 
>> Eh? Maybe you are using the word "graph" like I use "document".
>> I don't find that helpful.
>> 
>>> 
>>> I don't understand what that means. What is the content of a graph?
>> 
>> exactly.
>> 
>>> But in any case, doesnt that directly contradict the previous sentence? 
>>> 
>>> But whatever, it seems very odd for TimBL to advocate that an IRI not denote a resource. Are you *sure* you have this right? 
>> 
>> Good catch Pat.
>> 
>>> 
>>>> 
>>>> How do Peter and Pat feel about that?
>>>> 
>>>> TimBL: Please let us know if I misrepresented your position.
>> 
>> You did.
>> 
>>>> 
>>>> Separately, Elsevier representatives Brad Allen and Alan Yagoda informed me that by "named graphs" they mean an RDF Graph that is referenced by a URI.
>>> 
>> 
>> I suspect that if you ask them whether they are happy to use that URI for a web document
>> and indirectly use it to identify the graph by implication, I suspect they would be OK with that.
>> 
>> 
>>> Right, that is what the term was defined to mean in the paper which introduced the terminology in the first place. 
>>> 
>>>> Resolution of that URI returns the graph contents (a g-text) via RESTful interaction.
>> 
>> That would make sense to me if you say
>> 
>> 	Resolution of that URI returns the document contents (a g-text) via RESTful interaction.
>> 
>>> 
>>> No, that simply does not make sense. Graphs do not have contents and do not interact RESTfully or otherwise. Graphs are mathematical abstractions, remember?
>> 
>> Yes
>> 
>>> An RDF graph is a *set* of triples.... 
>>> 
>> 
>> Yes
>> 
>>> Maybe if you can say what you mean using the terminology we have all agreed upon, I might be able to figure out what you are saying. 
>>> 
>>> Pat
>>> 
>>>> That would seem to be in line with TimBL's preference.
>>>> 
>>>> Regards,
>>>> Dave
>> 
> 
>

Received on Wednesday, 14 December 2011 19:40:39 UTC