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

At 08:00 26/02/2002 -0500, Jonathan Borden wrote:
[...]

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

I should leave this Pat; the only reason I jumped in was I thought I saw a 
little confussion I could straigten out.  In my experience, though I should 
have known better as I usually find I'm the one confused, not Pat.

What I was trying to say was "don't use the word statement" because its 
confused in m&s.

An arc in the graph has a uri ref at its blunt end (i.e. as its subject).

A reified statement has a resource as its subject.

If one of you uses the term "statement" to refer to the arc in the graph, 
and the other to mean something in the domain of discourse, you are going 
to think you are disagreeing when you are not.


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

Pat should answer that, but I don't think so;  the distinction is important.
[...]

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

If you want a tutorial on model theory you should ask Pat.  My 
understanding is that the foundation of the model theory treatment of 
modern language is:

   o there is a language in which expressions are constructed (syntax)
   o there are 'worlds'
   o there are relationships between expressions in the language and worlds 
called interpretations

Part of an interpretation might say the symbol "Brian McBride" denotes me, 
the thing that weighs to much, is to old and can be poked in the eye.

Thus http://www.w3.org/ denotes something, but I don't think that it 
denotes a sequence of bytes.  I think it denotes some abstraction, and I'm 
not sure what properties of that abstraction I can rely on.  So I believe 
that something can denote something for which there is no representation.


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

Right.  And that's why its wrong.  The subordinate relationship it uses 
does not match the constraint we have to live with.


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

there was no semantics in my use of the term "partof" - replace it with 
"subresource" and my comment should still be meaningful.

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

I pretty much agree with what you are proposing, I'm just picking up on a 
little nit.


>(Note, the term "subresource" is used in other specifications, e.g.

I didn't know that.  I'm so ignorant.

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

Aha - the same trick I was suggesting.  Lets just use guid's huh, then we 
won't get confused.

Brian

Received on Thursday, 28 February 2002 01:48:53 UTC