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 Tuesday, 8 April 2003 13:12:02 UTC