Dan,
A bit of a clarification here. While the FEDORA page that you refer to
does indeed indicate 'per-application methods' I would not say that
FEDORA or we (at Cornell) propose them. The essence of FEDORA is 1) a
distributed, extensible, and uniquely identified type (behavior) system
2) distinguishing between types (behaviors) and their implementation and
3) the ability to associate these types (behaviors) with containers of
digital content. Since our FEDORA implementation is indeed CORBA based
types are defined as a set of methods and we have constructed samples
demonstrating extraction of DC metadata using methods such as getDCField
and getDCRecord. One could also use FEDORA to construct methods such as
ASK where the argument was some SQLish expression mentioned by you.
I agree with your comment that fine method granularity could get out of
control. However, its advantage is that it offers some rudimentary
"explain" facility - e.g., one of the 'native' methods in FEDORA is
allows asking a digital object "how can you behave" in which case the
architecture returns the list of methods available on the object. We
recognize that the name of a method is not necessarily self-explanatory
of its semantics, but its a start.
Finally, these interesting issues concerning modeling of digital content
and its interfaces are dealt with in an interesting paper by, Naomi
Dushay, one of our researchers at
http://cs-tr.cs.cornell.edu:80/Dienst/UI/1.0/Display/ncstrl.cornell/TR20
00-1807
Carl
Carl Lagoze, Digital Library Scientist
Department of Computer Science, Cornell University
Ithaca, NY 14853
Phone: +1-607-255-6046
FAX: +1-607-255-4428
E-Mail: [log in to unmask]
WWW: http://www.cs.cornell.edu/lagoze/lagoze.html
> -----Original Message-----
> From: Dan Brickley [mailto:[log in to unmask]]
> Sent: Monday, August 14, 2000 5:52 AM
> To: Anthony Finkelstein
> Cc: Reitzel, Charlie; [log in to unmask]
> Subject: RE: 'Has Part' qualifier query
>
>
>
> Since there'll be *way* more than the 15 DC properties, I'm
> inclined to
> the latter. I want to be able to send a message to a Web object
> saying: "tell me your DC::title and your XYZ::rating". If you map
> document properties onto methods, that's two method calls by
> necessity. If you take the ASK/TELL metaphor more seriously, you could
> either have this as two calls to ask (passing in the property name,
> ie. DC::title or XYZ::rating). Or you could have it as one call to ASK
> passing in an SQLish expression such as:
> "SELECT ?T, ?R FROM [?URI] WHERE DC::title(?URI,?T),
> XYZ::rating(?URI,?R) "
>
> In which case, a generic method on the object wins over having 15
> different per-property methods. Interesting to contrast this with the
> Fedora model btw., eg: http://www.cs.cornell.edu/cdlrg/FEDORA.html
> where they propose per-application methods, 'getDCField','getDCRecord'
> etc.
>
> Dan
>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|