Re: Subgroup to handle semantics of HTTP etc?

Dear TAG,

On Oct 17, 2007, at 10:11 PM, Tim Berners-Lee wrote:
> 	I agree that these semantics should not be considered part of the  
> semantics of the document.
> I think what you are getting at is that the semantic web  
> function    G(u)   which is the graph you get from looking up the  
> URI u should not be polluted with HTTP stuff.  In that I agree.  It  
> is a avery important architectural principle.

I would put the question like this: If I have a URI for an  
'information resource', which 'information resource' is it supposed  
to denote (in RDF)? If you can figure out accurately, based on what  
happens during HTTP (or using any other general rule), what it is,  
then [semantic] web architecture should specify what the mapping is  
(from HTTP behavior to IR).  If not, then we have to have a  
convincing story that tells us EITHER (a) why it doesn't matter or  
(b) how you ARE supposed to figure out which IR is denoted. (Unique  
identification of the IR, as in Pat Hayes's account [1], would be  
lovely but I'm not an identity purist - I might settle for a class of  
IRs or a sort of pronoun, an accurately (but not necessarily  
precisely) specified constraint on what it could and couldn't be.)

Equivalently, if I have an independent definition of a URI as an IR,  
is it possible for an HTTP server to behave inconsistently with it?  
And if so, which one is to be seen as "right"?

Accurately specified denotation without an explicit definition would  
be a very nice thing, since it would explain current practice, in  
which people freely use http URIs to refer to IRs, and don't feel the  
need to define the URIs in ontologies or other RDF documents (and how  
would you define *those* documents' URIs? how would you bootstrap?).

I would be very interested in helping to figure this out, since a  
believable account would not only be technically liberating but would  
also boost the http semantic web's credibility outside our own little  
world (e.g. in classical IT, library science, publishing, science,  
etc.). It may seem like nit-picking right now, but I'm pretty sure  
that if not solved this issue could be an impediment to adoption and  
scalability in the next 5 years.

It seems sort of risky to invest time in working on solutions if  
there is no kind of sanction of a particular clarification-activity  
by the TAG. This is my interpretation of the message from Tim that  
started this thread.

Best
Jonathan

[1] http://esw.w3.org/topic/HCLSIG_BioRDF_Subgroup/Tasks/ 
URI_Best_Practices/Recommendations/StatusOfHttpScheme

Received on Friday, 19 October 2007 12:09:39 UTC