Re: SIMILE clients (was: SIMILE Research Drivers)

On Wed, Apr 09, 2003 at 02:39:59PM +0100, Seaborne, Andy wrote:
> Hi Kevin,
> 
> That list isn't a covering of the space of possibilities.  It talks about
> caching but I'm not sure if you mean this is a formal or informal sense.  It
> talks about owning data but a fact like "this paper was published in 2003"
> isn't owned although there are provenance issues about that statement.
> 

When talking about a fact like 'this paper was published in 2003', the
fact may be objectively true regardless of who owns the statements 
that assert that fact, but there are still owners.  The owner is the
person who can be bothered to enter the fact into a database, and 
maintain it over time.  I don't mean own in a proprietary or exclusionary
sense (normally facts aren't protectable in that way), but in a 
curatorial sense.   Who has the responsibility of representing and
maintaining the fact.

> One knowledge worker task is asking a query of SIMILE, retrieving some
> information and holding that locally because it will be used localy, merged
> with other information, annotated locally (and used offline).
> 

If the facts are being separately maintained then the knowledge worker
in question has become a peer, and fits into category 1.

[...]
> In 3. you talk about client-level data cache and leases and in 4 you talk
> about HTTP caching.  What about the simple case of an application on a
> client machine issuing a query on SIMILE to retrive some information?  This
> isn't your case 3 because you have the condition that the server owns the
> data and that isn't part of my mental picture of what is going on here.
> 

Who are you intending should own the data after it has been returned to 
the user?  If it is the client then it falls under case 1.  If ownership
is retained by Simile then it falls under case 3.

> > Genesis will be attacking 1, and a little bit of 2 for special case data
> types. 
> 
> Great - what is the most update description of Genesis?
> 

See my response under seperate cover.

> 	Andy
> 
> -----Original Message-----
> From: Kevin Smathers [mailto:ks@micky.hpl.hp.com] 
> Sent: 8 April 2003 18:35
> To: Seaborne, Andy
> Cc: 'SIMILE public list'
> Subject: Re: SIMILE clients (was: SIMILE Research Drivers)
> 
> 
> Hi Andy,
> 
> On Tue, Apr 08, 2003 at 03:56:22PM +0100, Seaborne, Andy wrote:
> > 
> > At one level "client" is any system that uses another, at another
> > level, it is something on the end users machine and also it is the 
> > software that is the UI.
> > 
> > I don't see use of SIMILE to be purely a browse/interactive use
> > pattern (IMHO the Semantic Web isn't about such usage patterns).  The 
> > data from SIMILE may be being used by another service or a system that 
> > is agent-like on the client, it may be portal of some kind.  SIMILE 
> > "publishes" so it does not know what use will be made of the 
> > information provided; peer-like, client application-like, other.  
> > There are likely to be HTML-generating ways into SIMILE, and initially 
> > these are going to be important routes in, but there should also be 
> > programmatic access for non-browser systems. A goo ddesign is then one 
> > where the HTML-generating route is just servics that use the 
> > programmatic route.
> > 
> > This may not be the same relationship as SIMILE system - SIMILE system
> > where there may be a trusted relationship or a design exchange of 
> > information.  It would be desirable to use the same technology but we 
> > should not assume that is so.
> > 
> 
> As I see it there are four different possible interfaces for distributing
> data in Simile:  
> 
> 1.  Peer-level ingest and publish.  This is the server to server interface
> mentioned previously.  In this interface each server owns its own data and
> is not responsible for the data in its peers.
> 
> 2.  Priveleged peer-level based on one or more of data replication,
> mirroring, 
> and federation.  In this interface each server cooperates to present an
> interface to a logically combined metadata store.
> 
> 3.  Client-level data cache.  In this interface the client may gain
> temporary leases on data records before returning them with changes to the
> server, but the server owns all of the data.
> 
> 4.  UI View level cache.  In this interface the client controller and model
> run within the application server that hosts the server.  Cache control is
> through the standard web protocols for HTTP caching.
> 
> Genesis will be attacking 1, and a little bit of 2 for special case data
> types.  The current Dspace implementation uses 4.  If I understand
> correctly, you are arguing that 3 is also important.
> 
> Why?
> 
> None of the use cases either imply or require user agents as far as I can 
> tell.  Is there a use case that is missing, or am I missing an implication
> of one of the existing cases?
> 
> Portals are described in the use cases, and are IMHO adequately addressed by
> 
> interface 1.
> 
> Cheers,
> -kls
> 

-- 
========================================================
   Kevin Smathers                kevin.smathers@hp.com    
   Hewlett-Packard               kevin@ank.com            
   Palo Alto Research Lab                                 
   1501 Page Mill Rd.            650-857-4477 work        
   M/S 1135                      650-852-8186 fax         
   Palo Alto, CA 94304           510-247-1031 home        
========================================================
use "Standard::Disclaimer";
carp("This message was printed on 100% recycled bits.");

Received on Wednesday, 9 April 2003 12:12:23 UTC