W3C home > Mailing lists > Public > public-rdf-wg@w3.org > October 2011

Re: Web Semantics for Datasets

From: Peter Frederick Patel-Schneider <pfps@research.bell-labs.com>
Date: Fri, 7 Oct 2011 09:12:48 -0400
Message-ID: <20111007.091248.469748889364991026.pfps@research.bell-labs.com>
To: <sandro@w3.org>
CC: <danbri@danbri.org>, <public-rdf-wg@w3.org>
For all HTTP clients?  Over all time?  For all
hardware/software/protocol/internet errors?  

Without knowing the boundaries of the "every" the proposal is
incomplete.

peter



From: Sandro Hawke <sandro@w3.org>
Subject: Re: Web Semantics for Datasets
Date: Fri, 7 Oct 2011 07:05:11 -0500

> On Fri, 2011-10-07 at 06:27 -0400, Peter Frederick Patel-Schneider
> wrote:
>> From: Dan Brickley <danbri@danbri.org>
>> Subject: Re: Web Semantics for Datasets
>> Date: Fri, 7 Oct 2011 04:53:52 -0500
>> 
>> [...]
>> 
>> > I suspect a bigger problem is the amount of personalised,
>> > cookie-mediated or session-based content out there, 
>> 
>> This is, I think, one of the problems with proposals that push a "state
>> of the web" aspect into the RDF Semantics.
> 
> Yes, many URLs behave like this, but my intention was to write the
> proposal such that these URLs simply cannot be used as the fourth column
> of true datasets:
> 
>         Consider a "graph naming" to be the association of a
>         graph name N with a graph G.  For the graph naming to hold,
>         every
>         successful dereference of N yielding an RDF graph must yield G. 
> 
> I think follows that a graph naming cannot hold if N is one of these
> cookie-based URLs.
> 
> There is some danger that if you use someone else's URLs in the fourth
> column in your dataset, you'll be unknowingly wrong, as they used
> cookies but you didn't know about it.  But I think any time you use
> someone else's URLs like this, there is some exposure.   In some cases
> it can be handled by not caring if you're wrong, I guess.
> 
>    -- Sandro
> 
>> [...]
>> 
>> > Dan
>> 
>> peter
>> 
>> 
> 
> 
Received on Friday, 7 October 2011 13:13:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:45 GMT