<dbooth> Harry: General impression is that they managed to escape talking about resources because they stayed at a low http level.

<timbl> Zakim can't hear me

Because they aren't talking about resources (or even "entities") they manage to escape a lot of the problems that have been troubling us.

<dbooth> jar: Each of us would probably find problems with the way they modeled things.

However, I do think it's a pretty good model of HTTP.

<dbooth> jar: There are a few names that are wrong. E.g., example 2.2.1. Above it they use the word "representation" but not in the same way as AWWW.

<alanr> 'morning

Good morning!

However, it is perhaps clever that they have escaped lots of problems by avoiding the use of class Resource :)

But I agree with DavidB, this does lead to some quotation/level-mixing problem.

<dbooth> dbooth: The main thing I realized in reading through these (and also trying to model this stuff myself) is that to model this stuff sensibly, we really need to start with an RDF model of RFC2616 -- pretty much a direct transcription. Otherwise everybody chooses a different starting point and there is always ambiguity about what the elements in that starting point mean.

dbooth: how could we add a "semantics" of resources to this document, let's do a go around.

dbkkt

do

jar: this document provides a starting point, but what needs to be added to this document to make it more complete?

<timbl> I prefer to have httph:* relations rather than the gratuitous reification of the http:Header{Name,Value}

alanr: it would be profitable to do a review coming from us, a "consensus" review.

+1

possible *and* profitable possibly :)

<dbooth> +1

alanr: lets use a wiki for the review, going over domains and ranges, names vs. things.

timbl: add other things, can rules tie it in to the previous rules we had, that would help connect it to other ontologies.
... one significant difference between this and tabulator is that tabulator normalizes a singular predicate for headers.
... that makes it much easier to write rules.
... so writing rules for other ontologies will allow us to clarify our communication to this other group.
... are they using it?

jar: it looks like they will, it's in draft.

The plan I think is to use it with EARL.

timbl: let's work though a more complex example, like 303.

stuart: no real problems, but they do seem to think "representations are resources" in first sentence of abstract.

<Stuart> The identification of resources on the Web by URI alone may not be sufficient, as other factors such as HTTP content negotiation might come into play.

<timbl> timbl: It would be good to be able to use this to illustrate each example in say the arch doc an/dor the HTTP spec with what happens in the HTTP, like chained 303 302 200 transactions.

dbooth: the best starting point is a direct description of RFC2616.
... Section 2.2.1 it uses RDF:Alt to have multiple content instances.
... Yet, in RFC2616 a single entity has *one* body.

So, let's make sure when we're making our comments to make sure we can "plug-in" our ontology resources.

<timbl> Oh they should not use rdf:alt (ever) and sepcifically they should use http:body_base64 and http:body (literal text) etc

<timbl> ^ comment for hte letter

I apologize about not making further progress, but I'm still working on a list of terms.

(had to get new visa, travel for a month almost non-stop)

<Zakim> timbl, you wanted to after this caution about the HTTP spec as a basis for an ontology as it was not written with a view to being a multiple

jar: how can we make concrete homework out this.
... and get people to do this.

timbl: the http spec was not written as an ontology spec, so it uses English in a careless fashion, so be careful when building an ontology straight from the spec.

<jar> http 2616 is internally inconsistent

<dbooth> harry: we identify a short list of main problems that we'd like to address with this document (name/thing distinction, no Resource class, use of rdf:alt etc.)

<timbl> yes, but may use words in wys not normal in other communities, and also doesn't really ddefie the relationshio betwen the resource ad the represn ettaion

<dbooth> harry: What can we use as a starting point for comments? Notion of resourc eis missing. Misuse of rdf:alt, etc.

jar: may not need to be addressed in this document.

<Zakim> timbl, you wanted to ask DBootrh how close this is to his rules

we need a modular hook to hook-up a more semantic notion of resource to this draft.

I'd say, just having a class for "Resources" added to this might solve the problem.

So, for example, EARL right now cannot handle recording HTTP, so you can't specify in test-cases what's going on with HTTP: like a client should send a request with this parameter, and the server should respond with this status code.

Meeting adjorned.

jar - I'm assuming you'll post these 'minutes' to the wiki in some form.