W3C home > Mailing lists > Public > www-tag@w3.org > August 2008

Re: newbie question about sparql and 200

From: Dan Connolly <connolly@w3.org>
Date: Tue, 19 Aug 2008 13:13:57 -0500
To: Dan Brickley <danbri@danbri.org>
Cc: Richard Cyganiak <richard@cyganiak.de>, Jonathan Rees <jar@creativecommons.org>, Alan Ruttenberg <alanruttenberg@gmail.com>, "www-tag@w3.org WG" <www-tag@w3.org>
Message-Id: <1219169637.4554.73.camel@pav.lan>

On Tue, 2008-08-19 at 14:18 +0200, Dan Brickley wrote:
> Richard Cyganiak wrote:
> > 
> > 
> > On 18 Aug 2008, at 15:35, Dan Connolly wrote:
> >> cwm used to equate a document with
> >> a graph that it got from a document, but that turned out to be
> >> a pretty limiting constraint, so we introduced the log:semantics
> >> relationship between them.
> > 
> > This is interesting, Dan. Can you share some details? What issues did 
> > you bump into when you treated HTTP documents and graphs as equivalent?
> > 
> > (Not pushing any particular POV here, just curious about your experiences.)

Hmm... now that you press me, I don't seem to be able to confirm
from records that we ever implemented the design that
equates HTTP documents and graphs. What I find is
that log:semantics was previously called log:resolvesTo :

date: 2001/09/21 20:44:07;  author: timbl;  state: Exp;  lines: +11 -9
Name change resolvesTo to semantics, hasContent to content.

  -- http://dev.w3.org/cvsweb/2000/10/swap/test/includes/t10.n3

> Equally curious: what are the pros and cons of defining log:semantics as 
> a functional property? ie. can http://danbri.org/ have two different 
> values for it? (I'm thinking about content and language negotiation, as 
> well as natural changes over time).

cwm treats log:semantics as functional by caching/memoizing; i.e. there
might be some other representation out there, but cwm won't
ever look for one once it has a value cached.

The pro is performance.

The con is that it can't model change over time, language
negotiation, etc.

That bothered me for a while until I realized we could implement
an analog to log:semantics that took a timestamp/event/message
argument in addition to the document/resource argument.
Or perhaps it could take accept-header arguments. That
way you could get other representations. We haven't worked
on any scenarios that need it, but the possibility of doing
it addressed my concerns about treating log:semantics
as functional.

Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
Received on Tuesday, 19 August 2008 18:13:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:58 UTC