Graph-State Resources (was Re: graphs and documents Re: [ALL] agenda telecon 14 Dec)

On Wed, 2011-12-14 at 19:39 +0000, Richard Cyganiak wrote:
> 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”.

+1 everything Richard says here.

In addition, again coming out of the LEDP workshop, I'm now thinking it
makes sense for our architecture for allow for things -- like TimBL's
"document" -- which if prodded can yield a graph serialization, but
which are not best conceptualized as a g-box / Graph Container.  (These
things include internal structures of programs written long before RDF
was invented, being exposed as RDF for interoperability.)

The best term I've come up with for them so far is "Graph-State
Resources."   I've generally eschewed "Resource", but at the workshop,
and reading more about REST, people seem to be very comfortable using it
as a general word for the thing whose state is represented in the bytes
that come back when you do a GET.  Really, they mean Web-Accessible
Information Resource, but they just call it a Resource, because in their
context that's the only kind of Resource worth talking about.  (RDF
obviously likes to talk about other kinds of Resources, too.)

So, anyway, I'm thinking that the Web-Accessible Information Resources
that we mostly care about are those which can represent their state,
when prodded by a GET, as an *RDF Graph* serialization.  I think that's
equivalent to saying their state can be encoded in, or completely
described by, an RDF Graph.   So, rather than saying they are simply
graph containers, I'm saying they have state which is --or appears to
be, due to some encoding layer-- an RDF graph.    Thus, "Graph-State
Resources".    

Any ideas for a better term?

Anyway, I think this modeling would rename log:semantics as foo:state.
That is, instead of:

 <http://www.w3.org/2011/12/13-foo.n3> log:semantics {  ex:s ex:p ex:o }

I'm suggesting we consider "http://www.w3.org/2011/12/13-foo.n3" as
denoting a Graph-State Resource, since via HTTP it keeps telling me its
state is represented by "@prefix ex: <>.\nex:s ex:p
ex:o .\n" (Content-Type "text/n3").   Also, since it keeps telling me
that, I know (at least in some context, and modulo prefixes):

 <http://www.w3.org/2011/12/13-foo.n3> foo:state {  ex:s ex:p ex:o }

or maybe it's rdf:graphState.

How we handle the time sensitivity of REST, I don't yet know.
rdf:graphState, like foaf:age is a contextualized predicate.  If you
want decontextualized modeling, so that you can merge assertions from
different contexts, you need to convert it, probably to something that
looks like a record of retrieval events.

In the case of TriG and datasets, we may be able to avoid the issue of
decontextualization: the dataset can be in the same context as some RDF
graphs.   That is, I think it makes sense to encode my retrieval
knowledge above in TriG as:

    { <> a rdf:Type4Dataset;  # means that in this dataset, the labeling
relation is rdf:graphState }

    <http://www.w3.org/2011/12/13-foo.n3> {  ex:s ex:p ex:o }
      
Make sense?

      -- Sandro


> 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 20:31:29 UTC