See also: IRC log
just made it.
Grabbing a cup of coffee and will dial-in shortly.
<dbooth> Scribenick: hhalpin
<jar> hello.
<jar> oops... i need to dial in
<jar> skimming http://www.w3.org/TR/Content-in-RDF/
what's the conference code?
awwsw# is not working for me...
conference code?
Ah. I see - sorry!
<timbl> Do we have a meeting now?
They manage to use "authorityname" property.
<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.
Discussion is over: http://www.w3.org/TR/HTTP-in-RDF/
See Stuart's Topbraid rendering:
<alanr> wrong in what sense?
Stuart: Notice that requestURI and authorityName are properties.
... The range is often left not there.
dbooth: objects, the range is requestURI is "RDFliteral".
... this is level-mixing.
<timbl> http://www.w3.org/2006/http#RequestURI
Stuart: I actually produced the diagram from the RDF.
<jar> i want to ask dbooth to describe most important differences between this document and a literal transcription of rfc2616
<timbl> I am unware of this diagram you are taling about
i'd like to think of how we can give them concrete suggestions so this can "hook-on" later in a modular way to resource diagram.
<timbl> The URI would be useful.
a "resource" ontology.
<Stuart> Not my model, but my rendering of the their RDF using Topbraid attached to: http://lists.w3.org/Archives/Public/public-awwsw/2008Sep/0009.html
Stuart: My diagram is from text "in-line" in document.
<timbl> http://lists.w3.org/Archives/Public/public-awwsw/2008Sep/att-0009/http.jpg
<timbl> is the diagram then
So, in other words, how could this work have a "hook" (possibly in domains and ranges) for a later, more specified working out of the notion of "resource"
<Stuart> BTW: The RDF in the document differs from the RDF at http://www.w3.org/2006/http
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.
timbl: what's the precise diff between your rules and this, seems close.
dbooth: I made a few simplifications, and this document made others.
... vaguely remember treated the content as a string.
... didn't go into business of encoding.
timbl: 2.2.1 in a test-case some of these encoding problems are important
<jar> sorry.
jar: I think that just starting the diaolgue with the editors would be the best place to start.
... a pair of wiki pages, one for us to discuss, another to send to them.
dbooth: start with one?
jar: sure. We just have to be clear what goes to the editors of this document.
... we are concerned with some issues they are not.
<jar> we will hang it off of
<jar> hang it off of http://esw.w3.org/topic/AwwswHome
<timbl> Like http://esw.w3.org/topic/HttpInRdfComments ?
<jar> will be http://esw.w3.org/topic/AwwswHttpVocabularyInRdfComments
<jar> Propose action on everyone to edit that page (not everyone at same time)
<dbooth> I just created http://esw.w3.org/topic/HttpInRdfComments
jar: should we continue this or make our own document?
<jar> Next meeting: 10/14
alternatives: let's go over terms for our document.
keep working on comments on this draft.
jar continues with his model.
we should keep our work compatible with theirs.
EARL is in RDF.
EARL: http://www.w3.org/TR/EARL10-Schema/
<jar> http://www.w3.org/WAI/intro/earl.php ?
<alanr> jar: I will call in 10-20 minutes
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.
<jar> yes
