- From: Pat Hayes <phayes@ihmc.us>
- Date: Fri, 23 Dec 2011 20:12:53 -0600
- To: Jeremy Carroll <jeremy@topquadrant.com>
- Cc: public-rdf-wg@w3.org
On Dec 23, 2011, at 7:06 PM, Jeremy Carroll wrote: > I did not participate in the g-snap, g-box discussion, which I realize is my loss and no reason to reopen it. > However, I am a little confused how an RDF Graph can be a representation? Right, it can't. > A representation, as I understand is something that can be the result of a Web GET > An RDF Graph is an abstraction. Exactly. > > A RDF/XML document, or a turtle document, is a representation (of an RDF Graph?), and a TRIG document is a representation (of several RDF Graphs?) > > Hmmm, oh I see, you use the term "Graph Serialization" for that. Yes. (Because "document" is also used, by some, more in the sense of the resource rather than its representation, which gives rise to confusion.) > The model does seem to have an extra layer in, perhaps motivated by TRIG that contains multiple graphs. The layers are: (1) The RDF thing that an HTTP GET pokes, which is identified by an IRI in the conventional HTTP sense and which emits representations of itself (or of its state at the time) when GETted. This was a g-box and is now a Graph Container, although that terminology is under attack as being too simplistic. (As others in the WG have pointed out, the exact nature of this might be up for grabs, since people scrape RDF from all kinds of sources including free text inside HTML, etc.. So the key idea, we seem to agree, is that it is something which might emit some RDF when poked appropriately, maybe after content negotiation. The term 'container' arose from a rather simpler picture.) (2) The RDF thing which is the representation which gets transmitted back from a G. Container when it is GETted (or otherwise has its state 'read' by some process), and which corresponds to a piece of RDF in some exchange syntax, such as RDF/XML or Turtle, and can be encoded and sent in a byte stream or a character string. This was a g-text and now is a Graph Serialization. (3) The actual abstract RDF graph, a mathematical set of triples. This is not the kind of thing that can be stored or sent anywhere, but it can (and should) be the result of parsing a Graph Serialization. This was a g-snap and now is an RDF Graph. People often use 'graph' loosely to refer to any and all of these, but that can easily lead to confusion. If you store a Graph Serialization in a file somewhere on the Web, you have created a Graph Container. The graph in (that is, the RDF graph which is got by parsing the Graph Serialization which is got by GETting ) a Graph Container might change from time to time, without the container changing. Typically, IRIs identify containers, but some are arguing for the possibility of also having IRIs which identify RDF graphs. > > I doubt this matters much, it seems to be that philosophical thing, where we can easily get hung up, while agreeing on the mechanics of how the technologies should interoperate. As you know, misunderstandings can easily arise when we argue using imprecise language, so we are all trying to stick to this overall picture and terminology. I guess that is philosophy, in a sense :-) Pat > > Jeremy > > > On 12/23/2011 7:56 AM, Pat Hayes wrote: >> On Dec 22, 2011, at 12:06 PM, Andy Seaborne wrote: >> >>> >>> On 21/12/11 20:47, Jeremy Carroll wrote: >>>> On 12/21/2011 8:47 AM, Kingsley Idehen wrote: >>>>>> Jeremy: >>>>>> I am advocating that the IRI denotes the graph >>>>>> >>>>>> >>>>> Why not the Graph Container? >>>> In my mental model of the world, we take a URL like: >>>> http://www.w3.org/1999/02/22-rdf-syntax-ns >>>> >>>> when you do a get, and ask for content type application/rdf+xml >>>> >>>> you get an RDF/XML document that encodes a graph. >>>> >>>> To me, the RDF/XML document is the representation, and the graph is the >>>> resource. >>> This isn't to be picky as such but to reflect the matter of being precise and consistent. At RDF F2F2, we resolved: >>> >>> [[ >>> In our documents, we'll use the terms "RDF Graph" for g-snap, "Graph Container" for g-box, and "Graph Serialization" for g-text >>> ]] >>> >>> The resource is the "Graph Container" that can be poked with GET to return the current state which is an RDF graph. >>> >>> The representation is the "Graph Serialization" that encodes that RDF graph. >> Agreed about being precise with terminology. But I would like to push back on the implicit assumption here that the resource must be a graph container. Why can a URI not be a name for an RDF graph directly, not via HTTP GET of course, but simply a name *for the graph itself*? So an RDF graph can indeed be a resource, seems to me, at least if we acknowledge the possibility of attaching a name to one of them. >> >> This was the idea of the original 'named graph' proposal, and there were reasons for this choice. In particular, we paid considerable attention to the idea of signing and authenticating secure RDF data. If I am putting my signature to some RDF content, I want it to be attached to the actual graph, not to a labile graph container that others can later modify. Failing this, I want to have secure, locked graph containers, but this is not a topic we have yet tackled. It is simpler and I think more conceptually correct to speak of naming the graph itself. >> >> Pat >> >>> In the above text, "the graph is the resource" mixes things up a little. The resource is a Graph Container that can produce an RDF Graph (a value; the container's state) on demand. >>> >>> I read >>>>>> I am advocating that the IRI denotes the graph >>> as >>>>>> I am advocating that the IRI denotes the RDF graph >>> The "denotes a graph container" is a common, but different, usage pattern. >>> >>> Andy >>> >>> >> ------------------------------------------------------------ >> IHMC (850)434 8903 or (650)494 3973 >> 40 South Alcaniz St. (850)202 4416 office >> Pensacola (850)202 4440 fax >> FL 32502 (850)291 0667 mobile >> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes >> >> >> >> >> >> > > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Saturday, 24 December 2011 02:13:41 UTC