- From: Seaborne, Andy <Andy_Seaborne@hplb.hpl.hp.com>
- Date: Tue, 8 Apr 2003 15:56:22 +0100
- To: "'SIMILE public list'" <www-rdf-dspace@w3.org>
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."); >
Received on Tuesday, 8 April 2003 10:56:43 UTC