W3C home > Mailing lists > Public > public-awwsw@w3.org > July 2008

Re: HTTP mechanics +1, IR semantics -1

From: Harry Halpin <hhalpin@ibiblio.org>
Date: Mon, 14 Jul 2008 22:36:01 +0100
Message-ID: <487BC6C1.1080003@ibiblio.org>
To: Alan Ruttenberg <alanruttenberg@gmail.com>
Cc: public-awwsw@w3.org, Rees Jonathan <jar@creativecommons.org>

Alan Ruttenberg wrote:
>
> As stated, this is not the activity that I signed on to participate in.
>
> Having a clear and well specified architecture based on sensible and 
> understandable documentation, that has the potential number to server 
> development in a wide variety of circumstances, including scientific 
> ones, is of interest.

Yes, this of interest.
> Serving a particular application, and by implication, suggesting that 
> it is the canonical semantic web application, does not.

However, if we want to actually merge data across applications, having 
some sort of provenance ontology (did we GRDDL to get this RDF? Did we 
use RDFa? Did we have to run it through some data-munging? Manually 
replace some URIs in a pipeline?) is absolutely a second crucial 
component of the architecture of the Semantic Web, once we have a basic 
normative algorithm for retrieving SemWeb data given a URI. To me, it 
appears that documentation URIs/information resources would be 
components of such a provenance ontology.

          take care,
             harry
> Do others concur with this assessment of the state of our activity, 
> and the desired activity going forward?
>
> -Alan
>
> On Jul 7, 2008, at 9:05 PM, Jonathan Rees wrote:
>
>>
>> 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. 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.
>>
>> 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.
>>
>> 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.
>>
>> (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.
>>
>> There's clearly a big cultural gulf here, though.
>>
>> 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
>>
>>
>
Received on Monday, 14 July 2008 21:36:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 14 July 2008 21:36:40 GMT