Modelling HTTP GET with RDF was Re: [URI vs. URIViews] draft-frags-borden-00.txt

Brian McBride wrote:
>
> As I see it though, the job is only half done.  We need a model theory,
> defined at TAG level, to explain how resources and HTTP work.

I note that the issue is not yet adopted -- perhaps what the TAG needs is a
real problem that causes some system/piece of software to fail. In the
meantime consider this (for the specific case of http based URIs).

(perhaps what follows really ought go to RDFIG etc, but since you have
raised the issue to the TAG, let me give my official 2p (you still have "p"
dont't you?)

What is returned after an HTTP GET is a literal, or perhaps represented as a
"data" URI, this HTTP transaction might be represented _in a very simplified
fashion_ as an RDF statement (and without URI escaping)

<http://example.org/doc> http:GET
<data:text/html,<html><title>example</title><body><p>This is a
document</p></body></html> > .

This is simplified because for each GET, one can assign properties of (among
others)

1) Time requested
2) Accept: (for content-negociation)
3) other HTTP request headers

and for each response, the body of the document/"network entity" is
qualified by HTTP response headers. In general this might be modelled with
bNodes etc.

So you see that the URI is mapped to a set of representations (the responses
to a set of HTTP GETs). This is diagrammed in REST, and can be modelled in
RDF in a relatively straightforward fashion.

So, to answer the question:

The "resource" is at the blunt end of the HTTP:GET arrow and the
representation (or "entity") is at the sharp end.

I suppose that one could adorn an RDF graph with HTTP:GET relations if one
wanted to integrate an RDF graph with a set of HTTP transactions.

>..Could approach things two ways:
>
>    - two domains of discourse and one man's syntax is the other man's
domain
>    - one domain of discourse and an HTTP get is a function from name cross
> setof mimetype to seq of bytes

Exactly. The latter.

>
> So arcs in the RDF graph are syntactic thingies with a sharp end, a blunt
> end and a line linking them and some labels.  The label at the blunt end
is
> string; in fact its a uri.  A use/mention problem in M&S is that its
formal
> model confused the syntactic representation of a statement with its
> denotation.  A statement turned out to be used as both in different
> places.  Someone was aware of the distiction because the glossary defines
> triple as a syntactic representation of a statement, if I recall
> correctly.  Now, the arc in a graph is a syntactic representation.  Its
> denotation is a reified statement, though the model theory doesn't
actually
> say that.  The concept of statement itself is downplayed.  The reified
> statement still takes a resource, not a name of a resource as its
> subject.

I thought I was doing well, but you lost me at the last turn above. "Its
denotation is a reified statement" I don't grok.

Pat made a statement in a prior email, regarding the subject of a statement
being a URIref, I argued it was a resource, and it occurs to me that these
two are essentially one and the same, that since there is a 1:1
correspondance between URIref and resource, that the two are essentially
interchangable as far as the MT is concerned. Is that fair?

> >>ref 'means' based on its syntax. I am suggesting that RDF treat URI
> >>references as opaque identifiers, and that it ought not be possible to
> >>derive meaning by parsing the structure of the URI ref.
> >>
> >>To the WG: does RDF mean to say otherwise?
>
> Hmmm, nice one.  RDF operates in the context of the web where there is a
> function GET (URI, setof mimetypes) to byteseq.  So far we have no formal
> connection between these, but maybe having one would be helpful.

GET is used for HTTP URIs, but in the RDF model, a URIref is a URIref i.e.
opaque. Perhaps we are saying the same thing.

>
> Hmmm, I think of that as a feature of the RDF/XML transfer syntax, not of
> RDF per se.  What comes out of the parser is absolute uris with option
frag
> id's - that's what's in the graph.  If the model theory is the essence of
> RDF, it operates on the graph and isn't bothered by this.  The graph
> contains only absolute URI's with opt frag id's - right?

Exactly, and treats this as opaque (particularly since rdf:aboutEachPrefix
was a) judged a syntactic device and b) removed).

> >
> ><RDF
> >   xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> >   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> >   xmlns:s="http://www.w3.org/2000/01/rdf-schema#">
> >
> >Those URL's don't *denote* anything in RDF, but it is sure important not
> >to type them wrong.
>
> Sure they do; I can do a GET on them.  I can get a representation of what
> they denote.
>

Just so I can be clear about when you say "denote": Are we saying that what
a URI denotes is returned by HTTP:GET? What about non-resolvable URIs -- can
they ever "denote" anything?

I interpret this to mean
> >>that the URIref http://example.org/Unicorn#LeftButtock either may not
> >>resolve at all, else may resolve to a piece of HTML
>
> Ok, I've been itching to say this; might as well do it here.
>
> I think the concept of subresource introduced by Jonathan isn't quite
right.
>
> The constraint that we have to live with is that HTTP only sends URI's
over
> the wire - it doesn't send the fragid.

True but "subresource" is not defined in terms of HTTP GET, particularly it
is not defined at all in terms of URI resolution.

> That means that if we want to get a
> representation of http://example.org/Unicorn#LeftButtock we have to
> retrieve a representation of http://example.org/Unicorn and the extract
the
> relevant part.  I suggest that strictly, the "partof" relationship is one
> between representations of resources, not necessarily between the
resources
> themselves, i.e. whilst it might be kinda strange, the leftbuttock in this
> example could be a cows left buttock, not a unicorns.

Yes, the "partOf" relationship applies to _representations_ of resources,
not resources. The "subresource" is simply the "concept" that the URIref
identifies, not the part of the document that represents it.

I am not saying that "subresource" implies "partOf", rather introducing a
term for what a URIref identifies _in the same way that a resource is
identifies by a URI_. That is to say, there is a 1:1 mapping between a URI
and rfc2396:resource and a 1:1 mapping between a URIref and subresource.

(Note, the term "subresource" is used in other specifications, e.g.
XPointer, we were trying to provide a clarification. Substitute "node" for
"subresource", reread the I-D and let me know if you have the same issues.)

Jonathan

Received on Tuesday, 26 February 2002 08:05:13 UTC