Re: Uniform access to descriptions

Alan Ruttenberg wrote:
> > I think "identifies" and "describes" are
> > appropriate terms.  My position is that [a] may be *described* as
> > something other than what it *represents*,
> I'm not entirely clear on what this means. Maybe it's the choice of  
> words. [a] is a URI. <[a]> is a resource (I'll write <a> for  
> shorthand now). It's not very interesting to describe or represent a  
> URI - we usually want to make statements about the resource. So do I  
> interpret what you say as <a> may be described as something other  
> than <a>? Or  <a> may be described as something other than what <a>  
> is about?

Gotcha.  I say <a> may be described as something other than what <a> is
about.  If <a> is described as something other than <a>, that would be
a URI collision, right?  IOW, one can't describe a resource as both "a
person" and "a document about the person".  But one may describe a
resource as both "a document about the person" and "a wiki page".

> > Right, why would they be?  That's the point, "a wiki page" is a
> > description of the resource, which has absolutely no relevance to
> > the representations of that resource.  Those representations are of
> > that specific wiki page, "topic".
> I think I'm getting mixed up with topic, "topic", the topic, etc.
> When you write "topic" what did you mean by that. Is "topic"  
> synonymous with [a]. If so, using a synonym isn't advised - hard  
> enough to keep track of what is going on as it is. If not, then I  
> don't know what you mean by 'that specific wiki page, "topic".'

The representations of <a> pertain to the "topic", which I quoted
because it should be read as "concept of the topic of the wiki page"
which I believe means "topic" is synonymous with <a>, not [a].  OK, I
won't do that anymore.  ;-)

> > Yes, it could, I didn't realize I was required to point out the
> > obvious in my example, which is only concerned with the resource
> > in the
> > here and now, not what changes might occur to the resource in the
> > future and how those might change HTTP response codes.  Are future
> > changes to the resource really relevant to the discussion here?
> > There is no implied permanence in a 303 response.
> I was trying to point out that the "This clearly means that no RDF  
> variant is available" isn't so clear. Which representations a server  
> responds with can depend on such things are how loaded it is (the  
> load is too high, I'll return a more compact representation), not  
> only changes in the resource. In fact, it's not obvious to me why  
> changes in the resource would affect which representations are  
> available at all. Summary: when I see "clearly" in a sentence it  
> makes me look closer ;-)
> > If [d] is a representation of [a], then it would be served with a
> > 200 OK, not a 303 See Other in my example.
> then it *could* be served .... That doesn't mean it *will* be
> served. There are no requirements that a correctly functioning server
> serve any representation at all, never mind serving every possible  
> representation it could.

Point taken.  Perhaps Pat's goal to "agree on some simple protocols" is
unattainable, but that would be required before my "clearlys" would

> > Well, I thought I'd use [d] instead of creating [e] and calling it
> > wiki.rdf although I see now that I probably should have.  Many  
> > different
> > wiki pages can point to wiki.rdf as a description of their resource
> > type, wiki.rdf in such case wouldn't be a representation of any of  
> > them.
> Are you trying to make a distinction between representation and  
> description by saying descriptions need not be complete, whereas  
> representations do need to be complete?

Nothing of the sort.  I'm saying that a description of a resource need
not be a representation of that resource.


Received on Monday, 14 April 2008 04:31:28 UTC