- 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>
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