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

On 14 Dec 2011, at 20:31, Sandro Hawke wrote:
> 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?

Graph-representable resource?
Graph-represented resource?
Graphable resource?
Graphy resource?
Graphery?

Graph-state resource is not bad.

The SPARQL 1.1 Graph Store HTTP Protocol calls this “RDF graph content” [1]. That's worse than “thingy”.

> 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.

That's not too far from the foo:snapshot that Andy has been throwing around. foo:stateGraph or foo:graph might also work. I'd prefer any of them to log:semantics, 

I think it's ok to say that successful HTTP retrieval implies a foo:state relationship. I think it would not be ok for this to hold the other way round: a foo:state triple should not imply anything about the expected result of a retrieval action. In other words, I think it must be ok for non-resolvable URIs to have a foo:state too.

> 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?

What's the use case for needing to know that in this particular TriG file, the relationship between IRI and graph is rdf:graphState?

Would the above entail anything?

Best,
Richard

Received on Wednesday, 14 December 2011 23:33:23 UTC