Re: FW: notes on use cases

Hi David,

> -----Original Message-----
> From: David R. Karger [mailto:karger@theory.lcs.mit.edu]
> Sent: 04 April 2003 06:09
> To: mick.bass@hp.com; Mark_Butler@hplb.hpl.hp.com
> Subject: notes on use cases
[...]
> 3.2.7
> 
> Two issues seem scrambled here.  One is "how are things named" and the
> obvious answer is "URIs".  A separate one is "Should there be
> canonical URIs that can be deduced from what you are looking for"?  I
> believe the answer to the second is no.  URIs should be opaque (for
> example, random to avoid collisions).  The process of "figuring out
> the right URI for something" is a type of search/retrieval problem.
> Instead of squeezing this search/retreival into a specialized "figure
> out the URL" task, incorporate it in the standard search framework.
> Any information used to define a canonical URL can instead be used as
> metadata on the object, and any knowledge of how to construct the URL
> can then be turned into a specification of its metadata.
> 

Randomness avoids collision?  I would say rather that federation
avoids collision, randomness only invites it.  In any case, I wasn't
trying to describe a system of URL naming which incorporates a 
query into the name, eg:

   http://google.com/search?q=switch+stoned+chicks&btnI=FeelingLucky
   http://www.apple.com/switch/ads/ellenfeiss.html

Rather I intended the description of naming to read as a system for 
identifying resources smaller than the atomic document.   The URL
remains the same, there just needs to be a way of interpreting additional
constraints on the content within that URL.  I think this is analogous
to the identification of a ViewPart to extract a particular view of
an object within Haystack (do I remember a SongPreview10Seconds View
Part, or something similar?).  In this case the preview isn't meant
to be an aspect of the part however, but a name, which should be 
interpreted by the part to extract the relevant information.

My intention was to insert the use case element that would lead
to a requirement for an architectural element which would 
extend the view to support the naming variant.

(apologies in advance for abusing haystack terminology)

> 3.2.8
> 
> I don't understand planned distinctions between type and class.

Type indicates how a name or URI should be interpreted.  Class 
indicates how a metadata subgraph should be interpreted.  

Arguably type is a function of XML Schema, but I'm less interested
in the syntactic content of the Literal, than I am in the semantic
meaning of the content of the Literal.  Type isn't an attempt to 
define that meaning, just a linkage to its interpretation.

Again borrowing from Haystack, Type would be analogous to the 
linkage between the ViewPart and the java class which implements
the view part.  From the slides you gave us I'm not sure how you
do that linkage, but one possibility would be to write a statement
with a reserved predicate (:Implementation) that identifies the
class as an RDF Literal.  

I meant 3.2.8 as a place holder for that linkage.

> 3.4
> 
> Distributed resources adds whole different scope.  It opens up a host
> of nasty problems of course.  We could avoid them by limiting our
> dealing of with distributed metadata to devising a simple
> block-transfer protocol, getting all the metadata to a single
> location, and dealing with it there.  The metadata might not be fully
> up to date, but it avoids a lot of trouble.  Since even in centralized
> scenario everything is hard, perhaps we defer distributed search?
> 

To my mind, Semantic Web without the Web is just Semantic Filesystem.

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 Friday, 4 April 2003 17:59:56 UTC