Re: Is a graph an information resource?

On Monday 12. October 2009 18:13:56 Chimezie Ogbuji wrote:
> See response below.

Ah, thanks! I didn't see it at first as it didn't show up in the threaded 
view of mine. Please disregard my other, now redundant message.

> > So, the way I interpret this is that what you call "networked RDF
> > knowledge"
>
> is an information resource, whereas the graph itself is not. Is this a
> correct interpretation?
>
> Yes.  The difference is very subtle but it is a part of SPARQL.  See the
> end of 8.2.2 (Specifying Named Graphs) - I remember this from the
> previous DAWG.
>
> "
> The FROM NAMED syntax suggests that the IRI identifies the corresponding
> graph, but the relationship between an IRI and a graph in an RDF dataset
> is indirect. The IRI identifies a resource, and the resource is
> represented by a graph (or, more precisely: by a document that
> serializes a graph). For further details see [WEBARCH].
> "

Ah, OK.

> My understanding is that this applies not just to the use of IRIs in the
> dataset clause portion of a query but to all IRIs of graphs in a
> dataset.
>
> At the time this distinction was made, I didn't quite understand it, but
> in reading web architecture literature more carefully, it makes sense to
> me.
>
> > I can see arguments for making this distinction, but I'm not sure it
> > is
>
> useful. In light of httpRange-14, such an interpretation would seem to
> dictate that when dereferencing a named graph via its URI, a 303 would
> need to be returned to redirect the client to an information resource
> with the data itself.
>
> If upon dereferencing a named graph via its URI you get a 303, all this
> says is that:
>
> "the response to the request can be found under a different URI and
> SHOULD be retrieved using a GET method on that resource. [..] The new
> URI is not a substitute reference for the originally requested resource.
> "
>
> If httpRange-14 *requires* the behavior above, that would seem very
> unfortunate IMHO.  I think that (intuitively) for resources that are
> represented by RDF triples it *is* the case that their ".. essential
> characteristics can be conveyed in a message."

It says: "If an "http" resource responds to a GET request with a 2xx 
response, then the resource identified by that URI is an information 
resource;"

Thus, if the graph URI isn't an information resource, we would need to use 
a different code, or recommend the use of #-URIs. 

I suppose that TAG findings are advices, we are not obliged to use it as a 
normative reference, but I would strongly suggest that we take httpRange-14 
as normative for our work, as it is an important clarification of things 
that have bothered the community for some time.

Nevertheless, I don't think we must change this now. Before the FPWD, I 
would just like to have a different term than "RDF knowledge". I may be 
exaggerating the problems it causes, and we are likely to chase out 
comments from the community if it is a real problem.

> > Actually, I've always looked upon an RDF graph as an information
> > resource.
>
> Do you mean an RDF graph in the abstract sense or its serialization (the
> difference matters)?

Errr, well, I would think that something abstract can't be an information 
resource, but an RDF graph can have several serializations, so the answer 
to that is question is neither. :-) I've more thought of it like "my URI 
identifies the information conveyed by the abstract graph, which can be 
serialized into many different document formats". The serialization isn't 
customarily identified by the URI, AFAICS, since it depends on the Accept 
header. Hmmmm, I haven't really thought this through...

Cheers,

Kjetil
-- 
Kjetil Kjernsmo
kjetil@kjernsmo.net
http://www.kjetil.kjernsmo.net/

Received on Monday, 12 October 2009 19:17:59 UTC