- From: Seaborne, Andy <Andy_Seaborne@hplb.hpl.hp.com>
- Date: Wed, 9 Apr 2003 14:39:59 +0100
- To: "'Kevin Smathers'" <ks@micky.hpl.hp.com>
- Cc: "'SIMILE public list'" <www-rdf-dspace@w3.org>
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. 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). I have a whole bunch of local information on my machine on (e.g.) RDF query including papers read. I want to have my notes; I want to have other information from people in my work group; I want information on web sites that are outside SIMILE. I would really like access to information in a SIMILE but I (as a user) have a clear idea of what is "mime" and what is elsewhere. 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. > 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? 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 09:40:21 UTC