AWWSW -- 13 Apr 2010

<mhausenblas> heya dbooth

plus z4

Doodle Poll

michael: wasn't sure of the goal of the poll. find out shared understanding?

jar: wanted to know what interpretation people favor
... wondering if the answer was obvious and i was missing somethign. timbl seems to have assumptions about how this works.
... relationship btwn resource and representations. two dominant theories: 1. not much relationship. 2. pretty strong relationship.
... tradeoff is whether you get to use a particular uri to name a particular thing.
... In option 2 you have to make up new URIs for things that you thought you had URIs for. But if the relationshp is loose and vague then you get to re-use URIs.

dbooth: In my proposed theory it is very clear when it is okay to re-use a URI and when it is not. It's a matter of whether assertions are in conflict.
... The basic idea is that a URI has a set of assertions that constrain its proper use.

jar: If the URI is just constrained to be a FRBR expression, then does that constrain GET behavior?

dbooth: I further assume that GET responses are statements made by the URI owner.

<jar> Suppose the URI declaration says: http://example.org/b is a FRBR expression with author ... and title ... written in year ...

<jar> Does the URI owner then have the freedom to make *arbitrary* GET 200 responses, or is he/she constrained by his/her own URI declaration?

dbooth: A 200 response in and of itsself says that the resoruce is an information resoruce.

<mhausenblas> http://lists.w3.org/Archives/Public/public-awwsw/2010Mar/0017.html

<mhausenblas> and timbl 's answer at http://lists.w3.org/Archives/Public/public-awwsw/2010Apr/0004.html

dbooth: I think I'm in camp 2 ("Bob is giving out bogus representations"), but the description wasn't clear enough for me to determine whether the representations were actually in conflict with the facts already known about the URI, which include the URI declaration that Bob made to Alice in the cafe, and the implied URI declaration that Bob made by issuing
... a 200 response.

timbl: People will draw the line in different places. Some will treat URIs like permalinks, and some will treat them more transiently. [paraphrased]

jar: suppose you're a robot, even if you have metadata, is there any inference you can draw?

<jar> timbl: Expectations vary by context (permalink vs. ?)

<jar> timbl: If the representation says X, then the resource says X

<mhausenblas> Michael: I always get lost in these abstract examples. may I propose to look into a concrete example ...

dbooth: If the resource is essentially a function from Request x Time to Representations, then the response tells you one of the function's values.

<jar> Example: try almost any DOI.

<jar> any URI of the form http://dx.doi.org/10.*

timbl: the front page of the NY Times *has* a function, but it isn't a function itself.
... you can say sameWorkAs if you get two representations back, but not sameAs.

<mhausenblas> ahm, well ... ok, has something different in mind (currently working on an OData - Linked Data gateway to perform SPARQL queries and ran into same problem)

timbl: the ad to buy something is different than the thing itself.

<jar> timbl: maybe we can work at two levels? can let people be sloppy?

dbooth: The difference between the ad for something and the thing itself is that there are different assertions that are true of them: if they are denoted by different URIs, there are different sets of assertions that constrain the resource identity of those URIs

<jar> timbl: from one, I learn about a whale. from the other, I learn the price of a book

timbl: if the background color of one is cream and the other is white, those are not relevant differences.

dbooth: the background color is noise that has been added to the signal -- additional assertions that have been added but which are irrelevant

<jar> timbl: (vary: header)

timbl: If you know that something is a FixedResource, then you can know that the background color is always cream.

<timbl> If something is a FixedResource then you can say that the backgorund colour is cream once you have done a GET got 200 and got stg with cream background.

jar: Suppose the metadata says that an image is a particular png file with high resolution. It seems to me that's not sufficient to infer that the thing is a FixedResource.
... You need additional assertions to constrain the representations, e.g., to know that it's a FixedResource.
... This should be written up somewhere.

<timbl> http://www.subbu.org/blog/2007/12/vary-header-for-restful-applications

timbl: AWWW tries to do that

<mhausenblas> looking at http://tools.ietf.org/html/rfc2616#section-14.44 seems none is not allowed (?)

<timbl> Vary: Date would be nice

timbl: the VARY header tells you which of the parameters you are sending (such as AcceptLanguage) it should consider in deciding what to send back.

<jar> which conneg parameters are being taken into account in deciding which rep. to send back?

<timbl> and Vary: None or Vary:

jar: I've been in touch with someone working on momento

<jar> memento

<mhausenblas> http://events.linkeddata.org/ldow2010/papers/ldow2010_paper13.pdf

<mhausenblas> An HTTP-Based Versioning Mechanism for Linked Data

<mhausenblas> Fig. 3 shows the Memento HTTP Request/Response Cycle

<timbl> Time is already in the http://www.w3.org/2006/gen/ont ontology

(more discussion of time and memento)

<jar> Need rules like: " If the representation says X, then the resource says X"

jar: We need rules like "if the representations says X then the resource says X", like speaksFor

dbooth: Can we relate this back to doodle poll option 2?

<jar> Bob is behaving badly because his reps. say things the resource doesn't

<jar> e.g. they say the book costs $8.95

dbooth: I would phrase that differently, that Bob is having badly because he is saying things that are in conflict.

timbl: But it's not just that it's in conflict, it's that the rep doesn't say what the resource says.

<jar> timbl: http: didn't need to address this, leaves "what the resource says" as an exercise to the reader

timbl: Roy was fine with the rep of a robot being a control panel for it.

<jar> ... roy was happy for the rep. of a robot to be a picture of the robot, or a control panel

timbl: So it's useful to have the resource tied back into the FRBR vocab.

<jar> dbooth: Want to understand further what that means - what's being said, what assertions?

dbooth: So timbl is saying that it's not just a matter of Bob making conflicting statements, it's a matter of Bob making unauthorized statements?

<jar> timbl: If I go to school and write an essay on the book - my report might talk about the price of the book - my essay would be about the wrong thing.

<jar> Z is a representation of Moby-Dick.

<jar> Z says price of Moby-Dick-book is $8.95.

<jar> Therefore, Moby-Dick says price of Moby-Dick-book is $8.95.

<jar> which is false.

<timbl> It was a mistake for someone to give me the URI and say "this is the URI of Moby Dick"

<timbl> If the representation, as parsed according to the mime type, and presentde, contains the information X then the resource arch:says X.

<jar> FRBR would allow advertising in an 'expression'...

<jar> Timbl: Question of how much damage is being done.

<jar> ... Degraded copy of an image is OK...

<jar> .. what's the damage, and the benefit. E.g., of an abridged copy.

<jar> ... There will be community differences in this regard, local conventions.

<jar> ... Looking for X, and finding X + advertising, is how things are. Benefit is economics, but there's a downside

<jar> Are robots possible? Won't they always make mistakes about topics etc?

<jar> timbl: Just keep the robots away from pages that will confuse them

<jar> timbl: We should build lots of robots, and push back on sites that break them

dbooth: A degraded image is like receiving a set of information that is a combination of (a) noise (i.e., extra, irrelevant information); and (b) a subset of the full information that you wanted.
... If we think of the idealized information as a set of assertions I, then the advertising on the side adds irrelevant information II and a lower resolution image gives you a subset S of I, so you have: dbooth: If we think of the idealized information as a set of assertions I, then the advertising on the side adds irrelevant information II and a lower re

<jar> dbooth: A degraded image might be a subset of what you wanted, PLUS noise such as advertising

I = Idealized information S = a subset of I (e.g., lower resolution image) II = Irrelevant Information (e.g., advertising added) Returned representation = II + S

<jar> dbooth: A human can filter out the II part

dbooth: And the assumption is that the receiving client is able to filter out II and ignore it.

timbl: On a good day the receiving robot ignores II and on a bad day the robot concludes that it should buy the product that is advertised (because it isn't able to filter out II)

jar: I'd like to see a lot more metadata written about Informatino Resources (IRs)

timbl: A typical web app will filter out the stuff that it understands anyway. I encourage creativity in new protocols by putting extra stuff in the metadata that is handled by clients. I'd love to see things about access control, whether the info is public, etc.

<DanC> (on a bad day the robot attributes the ad to the article author, i think)

<jar> timbl: I encourage creativity in metadata... access control... pointers into source code control...

jar: I'm worried about things like DOI and the bibliographic ontology. It would be nice to have a consistent story about when you can write metadat like that. But it's tempting to write metadata that violates the rule that we just wrote down.
... if you have a URI that gives 200 responses and a LINK header, which describes some resource. You'd like to attribute the rep to the resource.
... But we've just given plenty of examples where you will get a price instead of the article.

timbl: Wonder if we should introduce a 233 that means "this is what you would have got from a 200"

<DanC> (ah... I was on the wrong example)

<DanC> (I certainly wouldn't recommend using the same URI for a book and an ad for the book)

<timbl> Danc +1

I won't be able to make April 27 either, as I'll be flying :(

<timbl> I certainly wouldn't recommend using the same URI for a book and an ad for the book)

<jar> meeting: AWWSW fortnightly

<mhausenblas> thanks dbooth for scribing - awesome job (as usual ;)

- DRAFT -

AWWSW

13 Apr 2010

Attendees

Contents

Doodle Poll

Summary of Action Items

Scribe.perl diagnostic output