Re: Announcement: "Cool URIs for the Semantic Web" - W3C SWEO IG Note

Hi David,

That is a rather large assumption! I don't see any particular reason
why real world entities should have consistent metadata anymore than
informational resources, which in some cases could have more stable
metadata if only because it is easier to control a information world
entity. Philosophy aside though, non-information resources being
represented by easily mutable metadata, or easily mutable data in the
case of web only resources, make it easy for people to change their
statements, hence they won't see a reason not to essentially if the
statement is in some way incomplete or incorrect according to their
view.

People are used to changing their web pages all the time and having
search engines regularly ping them or users come regularly to retrieve
updates is just part of the information culture. SemWeb has to deal
with that culture in some way instead of rejecting it based on an a
priori philosophical assumption that people will recognise meaning and
attempt to standardise it for the benefit of others who don't wish to
acknowledge their ability to update and change their publications as
they wish.

Even in the life sciences area, it would be most unhelpful if the
current definition for a term was never updated with newly discovered
relationships to new terms, and it is overly burdensome to insist on a
new version everytime a change happens. If you insist on versioning
you must explicitly retrieve each new version anyway, at least with
the dc versioning terms, leading to more bandwidth, storage and
processing required.

Cheers,

Peter

On 10/04/2008, Booth, David (HP Software - Boston) <dbooth@hp.com> wrote:
> Hi Peter,
>
>  The intent of using URIs in the Semantic Web to denote particular non-information resources is that the meaning of a URI should not change, and thus its metadata (or "URI declaration") should not need to change much.  Nonetheless, as you note, in a domain like news there may be desire to update the metadata more frequently than in a domain like life sciences.
>
>
>
>  David Booth, Ph.D.
>  HP Software
>  +1 617 629 8881 office  |  dbooth@hp.com
>  http://www.hp.com/go/software
>
>  Opinions expressed herein are those of the author and do not represent the official views of HP unless explicitly stated otherwise.
>
>
>
> > -----Original Message-----
>  > From: Peter Ansell [mailto:ansell.peter@gmail.com]
>  > Sent: Thursday, April 10, 2008 2:28 AM
>  > To: Booth, David (HP Software - Boston)
>  > Subject: Re: Announcement: "Cool URIs for the Semantic Web" -
>  > W3C SWEO IG Note
>  >
>  > On 10/04/2008, Booth, David (HP Software - Boston)
>  > <dbooth@hp.com> wrote:
>  > > > From: Peter Ansell
>  > >  > [ . . . ]
>  > >
>  > > > I always thought 303 redirects were not cacheable... "The
>  > 303 response
>  > >  >  MUST NOT be cached, but the response to the second (redirected)
>  > >  >  request might be cacheable"[1]
>  > >
>  > > > [ . . . ]
>  > >
>  > > >  [1]
>  > http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.4
>  > >
>  > >
>  > > True, but all that really means in practice is that a
>  > > client must not assume that the server response at time t+1
>  > > will be the same as it was at time t.  But if the client is a
>  > > SWeb application, does it really care whether the response
>  > > might be different at a slightly later time t+1?  Probably
>  > > not.  It will probably be perfectly content using the data it
>  > > got at time t.  In fact, to avoid inconsistency, most SWeb
>  > > applications probably would *prefer* to repeatedly use the
>  > > same time t data during a single program execution, rather
>  > > than use some data from time t and some from time t+1, in
>  > > case the server was in the process of updating the data.
>  >
>  > Heck, rules are made to be broken... why not! SemWeb apps are afterall
>  > special ;-) The data contained in the response from the final url can
>  > be cached if it is 200 coded and not header restricted by a
>  > non-cacheable statement. It is just the 303 redirect response that
>  > should be resolved to determine whether it still points to what the
>  > resource which gave you a 200 cached document last time.
>  >
>  > Caching responses may be okay in certain domains where the knowledge
>  > is known to be of a certain quality and stability but it is definitely
>  > going to be an issue in changing environments where 303's are used by
>  > definition to provide a non-cacheable response code which redirects
>  > the user to another separate resource as the server deems necessary. I
>  > think that any discussion of 303 redirects should include a disclaimer
>  > about their intended use and the specific conditions that were put
>  > onto the code by the RFC so people don't think it is just a general
>  > purpose specifically cacheable redirect that can be followed to the
>  > same result everytime.
>  >
>  > If the semantic web ever becomes popular in the fastmoving news area
>  > this would be an important distinction, as opposed to the more stable
>  > life sciences area which I and others are currently more involved in.
>  >
>  > Peter
>  >
>

Received on Thursday, 10 April 2008 21:33:45 UTC