Re: [Fwd: [GRAPHS] g-box, g-snap, and g-text]

Looks like a healthy conversation.  Just one comment now (maybe more later)....

On Fri, Feb 25, 2011 at 12:01 AM, Nathan <nathan@webr3.org> wrote:
> ...
> in linked data terms, I very much see an "information resource" as being a
> g-box, identified by an URL (absolute-IRI with an http scheme), which when
> poked (when you GET it) returns back a g-snap (rdf graph) which represents
> the current state of the g-box/ir encoded in a lexical data format, a g-text
> (a representation).

In this case we've got a terminological turf war.  People like to
stretch 'information resource' so that they can use URIs the way they
like and still nominally stay within the httpRange-14 resolution. But
this use of 'information resource' is definitely *not* included in
TimBL's definition or in the way I use it in the 'requirements' draft.
In these, RDF graphs and g-boxes cannot be 'information resources' -
only their serializations can be.

In fact saying a 'g-box' is an 'information resource' should be
logically inconsistent with my axioms. The reason is that if all of a
URI's authorized readings are serializations of an RDF graph, then a
'bound' 'information resource' has to be a [generic] serialization of
an RDF graph - it cannot itself be a graph.  (This explains why 'bound
to' has to be an 'if and only if' relationship... so this exposes a
bug in the axioms... and I am very grateful to you for helping me see
this!  This is a crucial point - you have to be able to infer things
about the 'bound' IR from the set of authorized representations -
otherwise it's possible to deny that the named IR has properties such
as 'serializes graph G', and the axioms have no consequence. I'll go
fix the document now!)

If you reject the TBL view I can't imagine any reason why anyone would
want to use the term 'information resource' other than to be able to
say you're following the letter of the httpRange-14 rule. If by the
term you mean the Roy Fielding 'resources' then you should say 'REST
resource', in my opinion, although as far as I can tell there's no way
to prove something isn't a REST resource, so that can't help much.

In order to talk rationally one of us will have to cede the
terminological ground. If you want to keep 'information resource' for
your own use (with RDF graphs a discriminating example), how about if
we work together to come up with a new term to use for the TBL/JAR
use, at least for the purposes of this discussion list? If we can't
come up with something better, maybe I will call them 'strict
information resources', the report becomes 'requirements for any
theory of strict IRs' and so on.

But before ceding 'information resource' to you for some different
purpose, I would insist on either a definition or an axiomatic
treatment that makes some sense. Without that I will have ceded
valuable territory for no good reason.

Jonathan

Received on Friday, 25 February 2011 14:25:22 UTC