Re: The meaning of "representation" (was: HTTP URIs and authority)

On 2007-10 -26, at 04:08, Mikael Nilsson wrote:

>
>
> Now, we're seeing a spectrum of views on what a "representation" in  
> HTTP
> sense might be.
>
>> From Xiaoshu's "I think there is no inherent
> relationship between a representation and resource, let along
> isomorphic."



> ... to Pat's "But yes, I'm assuming that webarch:representation is
> something like taking an imprint from a platen. It has to in some
> sense be a 'faithful' representation of 'all' of the resource."

Xiaoshu is writing about a completely different architecture, which  
has no concept of Information Resource.
<http://dfdf.inesc-id.pt/tr/web-arch> a :MisguidedDocument.

Pat is pushing bounds and trying to test his and our understanding of  
the AWWW.
<http://www.ihmc.us/users/phayes/PatHayes"> a  :FalseDocument.

> Both of the above cannot be true, and allowing both interpretation  
> hurts
> web architecture. The HTTP spec provides no real guidance.
>
> I propose that the TAG provides the community with a single,  
> consistent
> view on this issue: "What is the relationship between a
> http:representation and a webarch:resource"?

Well, the mapping between th conceptual resource
In fact, the relationship includes social as well as technical aspects.
It also is defined, often, by high-level protocols.
These higher level protocols set common expectations between the
publisher and the reader.  These are not consistent across the web.
That is why you can't simplistically just give a formula for that  
relationship.

Take my FOAF file, <http://www.w3.org/People/Berners-Lee/card>

There is information in it in RDF which sys that I made it
and it is my public profile document.
In fact when you get any representation of that document, the  
semantics of that representation will:

- Contain information about me which others may find generally useful
- Contain an amount of data it is reasonable to download over the net  
in typical circumstances
-  Not contain lots of other random stuff to waste your time
- Include recent updates but not necessarily be complete
- Be imperfect
- Include things fixed which people have pointed out to me
- Mention public acquaintances but not all personal friends
- Have exactly the same RDF triples independent of which content-type  
is dereferenced.
- Include pointers to acquaintances' FOAF files so you can explore the  
linked data graph;
- Contain normally the same things as it did yesterday. Incremental  
change.

That is the relationship between the conceptual work and  
representations you will get.
You can see it is up to me, but my reputation is at stake if I break  
these things.
It involves all sorts of out of band concepts.

Note that here the content negotiation is ONLY used for convenience of  
people who prefer RDF/XML or N3.  There is no difference in the  
information content  AT ALL.    (There are URIs for the content-type- 
specific version but they are really for debugging only, and should  
not be used to refer to my FOAF file.)

The use of web pages, data or HTML, the operation of these sort of  
invariant, these sort of expectations.
These expectations are very important to the web working.   That's why  
you can't just write down a formula for the constraint on the  
representations of a given resource.

In other cases,  the answers to these questions may be different, say

or - The representation will never under andy circumstances and its  
sha1-hash ends 18ec79817f345.
- The accuracy of an image will be much better in the SVG version  
than  the JPEG.
or -  The representation is available in many languages, with some  
loss in translation
or = If you understand N3 rules you will get more information than if  
you understand RDF.

These last three are cases in which there is some degradation for some  
or all content-types.   Degradation is useful for wider re-use with  
different devices,  but it means that you can't be so mathematical  
about what a resource "is".   It is useful but should be used very  
carefully.  When a publisher uses content negotiation to serve  
representation where different content-types do not convey exactly the  
same information, she should be very careful to really be happy that  
as far as she is concerned, she doesn't mind which one people get.

The AWWW tried to explain how these things work.
As we write more and more semantic web software,  one can to a greater  
extent see the way things work exposed in the software.

The very important class of documents, Information Resources, works,  
is very important in our society.  Works have properties including  
licensing, ownership, authorship, distribution, access control,  
licensing, review, and so on. These all really are not concerned about  
what content-type is used on the web.

Tim






> /Mikael
>
> tor 2007-10-25 klockan 21:40 -0400 skrev Chimezie Ogbuji:
>> Noah Writes:
>>> Your view seems to be that the resource needs to, at least in some  
>>> sense, be
>>> isomorphic to the representation, so you infer that when the  
>>> representation
>>> changes the resource must have changed.  It seems to follow
>>> that in the case of conneg, the resource must in some sense be (or  
>>> be
>>> isomorphic to) the union of all served representations.
>>
>> This view is actually consistent with the normative behavior for  
>> GRDDL
>> that we settled on with regards to content negotiation:
>>
>> http://www.w3.org/TR/grddl-tests/#langconneg3
>>
>> In the case of GRDDL, the 'maximal' GRDDL result (the RDF merge of  
>> the
>> renditions of each of the representations) is an acceptable rendition
>> of the original IR.
>>
>>> My preferred view is that
>>> there is allowance for changing policy as to how a particular  
>>> resource is
>>> represented, and that such changes to not necessarily imply that  
>>> the resource itself has changed.
>>
>> With such an allowance, a GRDDL-aware agent would not be able to
>> assume much about the IR behind the RDF rendition.
>>
>> -- Chimezie
>>
>>
> -- 
> <mikael@nilsson.name>
>
> Plus ça change, plus c'est la même chose
>

Received on Sunday, 25 November 2007 00:09:43 UTC