Re: resource and representation

On 2002-07-04 21:09, "ext Paul Prescod" <paul@prescod.net> wrote:

> 
> Patrick Stickler wrote:
>> 
>> ...
>> 
>> So when a Semantic Web agent dereferences the URI denoting an RDF
>> Schema containing statements, what it gets back may not be that
>> actual schema, yet it may in fact be encoded in RDF/XML so the
>> agent has no way to know if the schema it recieves is the actual
>> and complete schema it asked for?
> 
> What it got back was a representation of the schema. Presumably the
> provider feels that that representation is sufficiently representative
> of the schema. You are trusting the provider in any case, so I don't see
> a problem.
> 
>> ....
>> And *here* is the crux of the issue. REST/HTTP is for human consumption,
>> and the fact that GET can return something other than the resource
>> (or as Jonathan puts it, a representation of 'full fidelity') makes
>> it unsuitable for the Semantic Web.
> 
> You have known since the beginning of the discussion that GET could
> return something other than the resource or "a representation of full
> fidelity." Now you are shifting the goal posts.

No. I didn't understand that GET could return something other than
a "representation of full fidelity".

I suppose given the fact that the Web is for people and folks
are usually pretty savvy about interpreting ambiguous results
while browsing, such "loose" behavior is acceptable.

But I don't see it working well if at all with software agents
who are unnable to discern that a photo of Paris is not Paris
itself. Especially if the photo is not given its own URI that
is separate from that denoting the city -- which is unlikely
to happen in practice, since after all, any bozo understands
that you can't GET the city of Paris.

>> ...
>> Fair enough, but in practice, folks *do* use the same URI to denote
>> both the non-digital resource and some representation of the
>> resource.
> 
> They cannot. By definition their URI denotes the resource (whether
> digital or not).

Well, ahem, tell that to the folks wanting a URI to denote both
an abstract namespace and a namespace document ;-)

>> That is *exactly* what will be *recommended* by having namespace
>> names resolve to namespace documents! No?!
> 
> Not at all. The URI does not denote the namespace document. There
> happens to be a well-established algorithm for certain kinds of URIs to
> fetch representations associated with them. That does not change what
> the URI denotes. If you are a programmer then you are probably aware
> that you can put a pointer in N hashtables and thus have N different
> things associated with that pointer. That doesn't change what the
> pointer points to.

Will the namespace document have its own URI? If not, how can
I express statements in RDF about the namespace versus the
namespace document?

I understand that in principle, the namespace URI denotes the
namespace and not necessarily every representation that HTTP
may return, but in practice, the URI is overloaded and hence
ambiguous.

>> ...
>> RDF is fully able to reason about both resources and representations
>> of resources. Presuming the resources and all its representations
>> have different URIs that are used consistently.
> 
> It would be trivial to extend RDF (or perhaps URIs) to make both
> resources and representations *first class*. And in fact, this is
> necessary because it is ALREADY THE CASE that some URIs have both an
> XHTML, and an XML and a Docbook representation. Therefore if you want to
> reason about them, you need a way of describing which representation you
> are reasoning about. Once you've solved this problem the solution for
> resources will just fall out of it.
> 
> How would you use RDF to say that the "fifth element of the XML
> representation of 'foo' is an element of type 'bar'" and the "'seventh
> element of the XHTML representation of 'foo' is an element of type 'A'".
>
> If, given the appropriate primitives (element numbering, element types,
> etc.) RDF cannot say this because it cannot address representations or
> distinguish between representations and resources then RDF is not yet
> sufficient to work with the deployed Web architecture. Once you can
> distinguish between representations, it will be trivial to add a little
> feature for distinguishing between representations and resources.

Well, RDF *can* work with different representations, if those different
representations are denoted by URIs.

If a single URI is overloaded, such that it "denotes" (insofar as HTTP GET
is concerned) the set of variant representations, then the problem is
neither with the Web nor RDF, but with common practice requiring less
resolution/precision than RDF does.

This is what I meant by the Web not having the same need for precision
than the Semantic Web. For the Web, its enough to have a single URI
that resolves to multiple representations -- because the Web is not
really concerned about distinguishing between them, insofar as
browsing is concerned. One URI does the job, and content negotiation
takes care of the rest "behind the scenes".

But as you point out above, the Semantic Web requires that the
distinction between variant representations and between representations
and the resource itself be explicit and consistently maintained.

In this regard, HTTP and RDF are in a way at odds, since to HTTP,
one URI is enough but for RDF that constitutes a problemmatic,
if not unworkable, ambiguity.

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Friday, 5 July 2002 06:46:28 UTC