SIMILE clients (was: SIMILE Research Drivers)

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.

	Andy


> -----Original Message-----
> From: Kevin Smathers [mailto:ks@micky.hpl.hp.com] 
> Sent: 7 April 2003 20:12
> To: John S. Erickson
> Cc: www-rdf-dspace@w3.org
> Subject: Re: SIMILE Research Drivers
> 
> 
> 
> On Mon, Apr 07, 2003 at 12:54:54PM -0400, John S. Erickson wrote:
> > 
> > Kevin asks:
> > > So the question I am left with is: why do you think
> > > that Simile clients should not be limited to web browsers?
> > 
> > Well, for one thing, the Haystack client is not technically 
> a "web browser"
> > 
> 
> I agree of course.  
> 
> Still this is the first suggestion I've seen that the Haystack
> client would be used with Simile.  My impression was rather that
> the Haystack UI would be ported, minus the client, using a Web UI
> interface.
> 
> > I think that we need to accomodate virtualization of the 
> storage that the
> > client interacts with. This storage should be assumed to be highly
> > distributed, and will include resources that are locally 
> stored (relative to
> > the user). The purpose for this localization might be for 
> performance reasons,
> > and/or because the user's activity simply suggests that 
> being "close" to the
> > physical context makes the most sense.
> > 
> > There could be reasons of control as well --- the 
> user/client might be
> > modifying a set of resources and thus (a) has a local copy 
> and (b) causes a
> > "lock" on "server" copies.
> 
> This is an interesting idea, but as the client code won't be 
> under the 
> control of the user, it seems impractical to require that 
> virtualization
> happen at the client/server interface rather than at the server/server
> interface.   
> 
> If I'm wrong and client code /is/ intended to be run by the 
> user directly
> then a client library that can span multiple repositories takes on a 
> greater significance, as well as implying the need for a 
> corresponding 
> web-service API on the server end.  This, assuming that DSpace hosts 
> aren't likely to want to expose the RDF database layer 
> directly to their 
> non-local clients.
> 
> I would suggest that there is little need for that style of 
> interaction
> with the Simile server however.  The distribution use cases for Simile
> (Shared Collections, Open Courseware) seem to rest on data 
> sharing at the 
> peer level rather than at the client level.  
> 
> 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.");
>