- From: Booth, David (HP Software - Boston) <dbooth@hp.com>
- Date: Tue, 4 Nov 2008 17:09:32 +0000
- To: "Michael Lang(Jr.)" <michaelallenlang@gmail.com>, Peter Ansell <ansell.peter@gmail.com>
- CC: John Graybeal <graybeal@mbari.org>, Michael F Uschold <uschold@gmail.com>, "semantic-web@w3.org" <semantic-web@w3.org>, aldo gangemi <aldo.gangemi@gmail.com>, Conor Shankey <cshankey@reinvent.com>, Peter Mika <pmika@yahoo-inc.com>, Ora Lassila <ora.lassila@nokia.com>, "Dr Jeff Z. Pan" <jeff.z.pan@abdn.ac.uk>, Tim Berners-Lee <timbl@csail.mit.edu>, Frank van Harmelen <Frank.van.Harmelen@cs.vu.nl>, sean bechhofer <sean.bechhofer@manchester.ac.uk>, "michaelalang@gmail.com" <michaelalang@gmail.com>
> On Nov 3, 2008, at 10:48 AM, Michael Lang(Jr.) wrote: > [ . . . ] I have this notion that *any* > change to a static resource's specifications -- definition, metadata, > semantics -- makes a new resource (this lets me compare resource_new > to resource_old and see the difference between them unambiguously). I think that's one good view that's right for some applications, but not the end of the story. For applications that can live with more instability, modifying a resource specification in place is the best solution. For others needing more certainty, the strategy that you describe is best. The most important thing is to clearly state the change policy of the resource specification. > > With this vision, the resource can't change once it is created, even > to point to a new resource (you see the problem). Is this vision just > plain wrong, per the consensus? I don't think this needs to be a problem, because a static resource specification could include the URL of an external document that can be updated without modifying the static resource specification. The URL of the external document *would* be a part of the static resource specification, but the content of the document at that URL would *not* be a part of the static resource specification. David Booth, Ph.D. HP Software +1 617 629 8881 office | dbooth@hp.com http://www.hp.com/go/software Statements made herein represent the views of the author and do not necessarily represent the official views of HP unless explicitly so stated.
Received on Tuesday, 4 November 2008 17:11:55 UTC