Re: Issue-57

[trimmed the cc list to just www-tag]

On Sat, Jun 25, 2011 at 11:42 PM, Tim Berners-Lee <timbl@w3.org> wrote:
>
> On 2011-06 -25, at 06:37, Ian Davis wrote:
>> Secondly what resource is denoted by the knox.edu URI? I content there
>> are several possibilities:
>>
>> a) the person called "Barack Obama". Perhaps further RDF statements
>> might say that resource is wearing a tie.
>
> No.
>
>> b) the photograph of that person as originally taken by the camera.
>> Further RDF statements might say who the creator of that photograph
>> was, or talk about the lighting used or the composition.
>>
>
> Yes.
>
>> c) the digital version of that photograph, perhaps scanned. Further
>> RDF statements might say the digitisation process or resolution.
>
> Well, in fact because the server could return different scans of the
> same photo under different conditions, and nothing would break,
> actually (b) not (c).  Of course the web works by sending digital
> encodings, but that doesn't mean that the URI names them.
>
>> d) the file format of that digital image. Further RDF statements might
>> state the compression factor, or refer to the EXIF data that JPEGs can
>> have.
>
> RDF statements expressing something of a given set of bits
> returned from the server would in many cases by in danger of being
> wrong as the server may return a different compression under different circumstances.
> So RDF systems if they want to can and do stored a record of the HTTP transaction
> keeping a record of the return headers and the bits.  There are various
> ontologies foe this.
>

I found this really surprising because I don't consider a) or b) to be
information resources as defined in AWWW. You are saying you expect
that URI to identify and return 200 for something that has mass, smell
and texture.

>> I think your statement is referring to d) but its' certainly ambiguous
>> in that sense. It can be disambiguated by publishing more data about
>> that URI.
>
> There are also HTTP vary:  headers which can help.
> There is the ontology http://www.w3.org/2006/gen/ont
> which you can use for expressing relationships between resource
> which are more or less specific when it comes to various axes.
>
>>
>> If you think I am wrong, then please tell me what this statement means:
>>
>> <ex:i>   <fb:like>    <http://128.252.39.97/SnapshotJPEG>.
>
> It means, given fb: and ex: as above, that I like the a rather
> washed out picture of some hall, which I don't.
> So it is a false statement.

That URI belongs to a webcam, so the image changes with time (i.e. a
set of time-varying representations). The resource identified is not
clear. My best guess is that URI identifies the scene within the
viewport of a specific webcam. That's clearly not an IR, which
contradicts the 200 response code. This is a typical webcam setup.

My wider point in this discussion is that we shouldn't be expecting
the majority of website operators to understand the difference between
an IR and everything else. Some things are clear cut, many more are
not, as hopefully my example with the photograph and webcam shows.
It's obvious when you just have a document in a file system, but that
is the web of 10 years ago. Today the majority of web serving is via
an app framework, database or script, generating representations on
the fly.

My position is that we should avoid forcing publishers to understand
the distinction between an IR and everything else, but give them the
mechanism to indicate it if they can. That can be as simple as putting
a wdrs:describedby triple or header somewhere. Or they could continue
to use 303 redirects. However I also think it's ok for them to serve
non-IR's up with a 200 response code.

It's up to the consumer of the resource to determine its nature, if
it's important to them. They can look for existing signals (303) or in
their absence, look at metadata in the representation or in the HTTP
responses.

Ian

Received on Monday, 27 June 2011 16:08:31 UTC