Re: services against collections

Yep, the underlying thing we are viewing is the *resource*. Any metadata
record is a surrogate for that resource, and thus a view.

Yes, I do think different views can reflect different conceptual models.
For example, one view might use descriptive conventions that reflect the
FRBR notion of a work (as abstract) and the other FRBR entities, while
another view might reflect the common notion in the museum and VR worlds
that a work is a concrete thing. Remember, FRBR is functional
requirements for *bibliographic records* - it models the bibliographic
universe, not the world. So FRBR itself is a specific view of the world.
A useful one, for us, but a view nonetheless.

So the "master" metadata record stored in a system does itself reflect a
particular view, a specific cultural norm, etc. We hope to be able to
generate different views from the master one (say, mapping to subject
vocabularies from a different domain), but no matter what we do we can't
overcome the reality that our master record itself reflects a specific
perspective on the world, no matter how much information it contains.

Jenn

> -----Original Message-----
> From: Next generation catalogs for libraries
> [mailto:NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Jonathan Rochkind
> Sent: Wednesday, May 23, 2007 9:56 AM
> To: NGC4LIB_at_LISTSERV.ND.EDU
> Subject: Re: [NGC4LIB] services against collections
>
> That's an interesting idea, but the concept "view" suggests
> that there is an underlying... um, thing, that you are
> _viewing_. There might be different views, but they are
> different views of the same underlying thing. If this is so,
> that underlying thing has to be a metadata representation
> too, doesn't it?  This doesn't to me seem to get around the
> fundamental problem here.
>
> To put it another way---do you think that one "view" might
> make _different_ decisions about Work-Entity-Manifestation
> relationships than other views?  If so... how could we
> possibly manage to control all that, we have enough trouble
> just trying to control _one_ set of decisions about those
> things.  And if so, that means that each "view" lives in it's
> own seperate universe, they aren't really just "views" of the
> same universe at all, they're entirely seperate universes,
> and if you have a case where you need to bridge those
> universes, you're going to have trouble, no?  But if not, and
> each "view" makes the same decisions about these things, they
> just _expose_ different aspects of the underlying decision
> (this is what is connoted by the very term 'view', right?),
> then underlying all those "views" is still a single metadata
> and domain model with a single set of decisions, we're back
> at the problem of trying to design a data set that works for
> everything---even if that dataset is _exposed_ in different "views".
>
> Jonathan
>
> Riley, Jenn wrote:
> >> So the response from some is now that we need to design
> the metadata
> >> for some particular new application, but we need to design the
> >> metadata to flexibly support many (any?) applications. Are
> we wrong
> >> to be thinking this? Is this a sisiphean task?  Do we need
> to specify
> >> the bounds on what sorts of applications we mean to support better
> >> (the FRBR user tasks are one attempt to do this; are they
> sufficient?
> >> Why or why not?).
> >> Should we specify the bounds all the way down to something as
> >> specific as one particular application? (The 'online public access
> >> catalog'?
> >> Surely not!)
> >>
> >
> > Sarah Shreeves of UIUC and I have been promoting recently
> the idea of
> > "shareable metadata" - that which is intelligible and useful in
> > metadata aggregations. We start from the notion that Carl Lagoze
> > championed in the early days of DC that all metadata is a
> *view* of a
> > resource - that it isn't possible to create a usage-neutral
> metadata
> > record. Our thinking here is that we don't have to design a
> view for
> > every single application, but that we can present a
> different view for
> > every major
> > *class* of applications - a Google-style view, and OAIster/OAI-PMH
> > style view, a collection registry-style view, etc. I think
> we have a
> > ways to go before we fully understand what those
> fundamental views are
> > and what metadata they should contain, but it seems to me
> that a happy
> > medium between designing for every single application and designing
> > for one single application is the way we should be thinking
> about this.
> >
> > Jenn
> >
> > ========================
> > Jenn Riley
> > Metadata Librarian
> > Digital Library Program
> > Indiana University - Bloomington
> > Wells Library W501
> > (812) 856-5759
> > www.dlib.indiana.edu
> >
> > Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com
> >
> >
>
> --
> Jonathan Rochkind
> Sr. Programmer/Analyst
> The Sheridan Libraries
> Johns Hopkins University
> 410.516.8886
> rochkind (at) jhu.edu
>