RE: HTTP mechanics +1, IR semantics -1

Hello Jonathan,

> -----Original Message-----
> From: public-awwsw-request@w3.org
> [mailto:public-awwsw-request@w3.org] On Behalf Of Jonathan Rees
> Sent: 07 July 2008 21:05
> To: public-awwsw@w3.org
> Subject: HTTP mechanics +1, IR semantics -1
>
>
> My notes from last Tuesday's telecon say the following:
>
> Tim's goal is to have an ontology [I would have called it an "RDF
> schema"], and maybe eventually feed it into a TAG finding. The
> ontology is to be driven first by what tabulator needs, then adding
> rules to cover some of the semantics of headers.

Personnally, I think that's a little cart before horse. The Tabulator is no doubt a great 'playground' for implemented what needs to be implemented, for experimenting with options and for demonstrating when things that we might think out to work don't or that things have not been explained enough that independent people would come to the same descision about how things should be. Whilst the tabulator, in the long run, may be an exemplar of correctness, I don't expected it to be the definitive thing.

> Then later, define
> what it means for something to be a semantic web client; such a thing
> should do the following things, among others: read rdf, do grddl,
> understand rdfa.

There may be some behaviours that the Tabulator exhibits that we might judge as being what all 'good' semantic web agents should do (ie. take it as inspiration).  There may be bits of behaviour where there would be universal agreement, others that are considered useful though but not essential, and other that are wrong and should be changed or abandoned. I simply don't know what Tabulators behaviours are.

> The ontology would be useful for caches and catalogs - the client
> would know what information is sufficient (on this day this server
> responded with an expiry date of ...) to reliably access resources
> without having to go to the web.

Sorry... /me has probably lost the plot... but I don't (now) have a good feel for the sorts of questions we'd br trying to use 'the ontology' to answer. Can you remind me of its scope, possibly with a few competency questions. Brain fade on my part I'm sure.

> Also desirable: an ontology for indicating how a server gives a hint
> to a client about multiple versions.
>
> Tim resisted the suggestion that it might be worthwhile to develop a
> better definition of "information resource" since he thinks this is
> not a question of ontological relationships in an open system but
> rather one of type checking in what Tim views as a programming-
> language-like notation. Tim has previously offered to answer
> particular questions of the form "is X an information resource" but
> now states that any effort to create guidelines that would answer such
> questions generically would be a waste of time.

:-) well there are such a large number of questions of that form, and probably no place where answers already given have been systematically recorded. One could spend a life-time answering such questions... it probably gets a bit wearying ;-).

> (End of notes.)
>
> That's fine, I can work with that. My hypothesis going back to last
> summer that there was synergy between Tim's aims and mine in this
> activity may turn out to be false, but so it goes. I suggest we work
> to get this simpler job (what I call "HTTP mechanics") out of the way
> as quickly as possible and declare victory. If a group not containing
> Tim wants to continue to talk about IRs, that's fine, and I see no
> reason it couldn't make progress.

Ok... though I don't know how we'd answer the question of "...is it ok to respond with 200 OK" - which seems pretty close in mechanical.

> There's clearly a big cultural gulf here, though.

Are you able to characterise what's on the ground either side of the 'void'?

> I do have a one or two remaining questions about IRs that are not
> related to the definition of the term, which I believe to still be in
> scope, and I will post these later.
>
> Jonathan
>

Stuart
--

Received on Tuesday, 15 July 2008 11:43:05 UTC