Re: use case clustering -- "collections"

Antoine, Jodi, others


Happy New Year!
 
(I'm awake again ...)
 
I think we've got two separate areas of focus: 1) the "obtain" function; 2)
granularity of metadata description. Both are interesting.
 
1) is concerned with a specific item (although it may be distinguished from
other items of the same manifestation merely by its "obtainability"), and covers
attributes such as loan status, opening hours for physical access, access
restrictions based on licenses, etc. as well as bibliographic attributes which
make a specific item "special" (e.g. missing pages, autographed by author,
previously owned by a specific person or group, etc.).
 
2) is concerned with what is being described by metadata: (in descending order
of granularity) a super-collection, a collection, a work and all its
expressions/manifestations/items (the traditional bibliographic record), a
specific expression/manifestation/item (a FRBRised "record"), a specific
attribute of a specific resource (an RDF triple).
 
I think we need to cover both areas in the LLD work, but not necessarily via the
use-case cluster mechanism. 1) definitely needs the use-case approach, but 2)
could be handled by adding a page to the wiki's Resources section (perhaps via
the Library standards and linked data page). As we've already discussed, neither
collection-level description nor FRBRised description are generally used by
libraries at present, so 2) is more hypothetical than practical. Of course, we
could just add two use-case clusters, one for each focus ...
 
I'm happy to add a wiki page on granularity (for 2)) if that's the approach we
agree on.
 
Cheers
 
Gordon

 


On 05 January 2011 at 18:27 Jodi Schneider <jodi.schneider@deri.org> wrote:


> 
> 
> 
> On 5 Jan 2011, at 11:29, Antoine Isaac wrote:
> 
> > 
> > Hi Gordon,
> > 
> > I'm sneakily bringing this thread up after your hibernation ;-)
> > 
> > I get your point re. the "peak collection"--that's a very interesting
> > scenario. Yet I'm a bit skeptical about focusing the entire cluster on
> > collections. Some cases could do without collection-level descriptions,
> > couldn't they?
> > As I understand Emma's (and your earlier) position, I'd rather keep to the
> > idea that this cluster is a family of "obtain" cases, with some of them
> > potentially benefiting from a collection contextualization. That won't give
> > us a nice title, but at least that would be less harmful for now!
> > 
> > By the way, what's the reason for which the AuthorClaim case is attached to
> > this cluster?
It depends how we define the cluster -- whether it's about "obtain" or about
collections.
> This line in AuthorClaim made me think it's about defining and creating
> collections:
> "Each expert makes a binary decision of a document belonging to a category or
> not."
> 
> 
> Some of the use cases in Collections could be interesting for Social Uses
> (again depending on how we distinguish those). So I'm hoping for more clarity
> about how we want to define each of these clusters. Further, Collections needs
> some curators. :)
> -Jodi
> 
> 
> > 
> > 
> > Antoine
> > 
> > 
> > 
> > > 
> > > 

> > > I, too, was thinking that the cluster is about the "obtain" task from
> > > FRBR. But then I remembered that another main utility of collection-level
> > > description is to identify "peak" collections focused on some aspect of
> > > interest to the user (subject, format, loan period, etc.) so that they
> > > could browse with a higher likelihood of finding the resource(s) they
> > > need. So a user might want to know not just the nearest library with a
> > > known item available, but also the nearest library with a good collection
> > > on medicine, or of VHS cassettes, or with items available for "holiday"
> > > loan, for non-known item browsing. So the metadata of interest to the
> > > cluster also supports the "find" user task.
> > > 

> > > 
> > > 

> > > Note also that collection-level description can be applied to collections
> > > of metadata (e.g. library catalogues, archival finding-aids, etc.), so has
> > > a "meta" task in organising the searching of multiple catalogues for
> > > federated, union, and linear/one-by-one resource discovery services.
> > > 

> > > 
> > > 

> > > I suggest just "Collection-level description cluster", and that we anchor
> > > its scope on previous work carried out by JISC, DCMI (and NISO) in
> > > developing schema for describing collections. I'm happy to put in
> > > additional mini-use cases (or just embed references in the cluster page)
> > > to illustrate collection strength and metasearch organisation
> > > applications.
> > > 

> > > 
> > > 

> > > 
> > > 

> > > But I'm not the best person to be objective about this suggestion, due to
> > > my close involvement with the Scottish Collections Network (SCONE) project
> > > and services ...
> > > 

> > > 
> > > 

> > > Cheers
> > > 

> > > 
> > > 

> > > Gordon (about to hibernate for the next 3 weeks ;-)
> > > 

> > > 
> > > 

> > > On 20 December 2010 at 15:05 Emmanuelle Bermes <manue.fig@gmail.com
> > > [mailto:manue.fig@gmail.com] > wrote:
> > > 

> > > 
> > > 

> > > > On Fri, Dec 17, 2010 at 11:18 AM, Antoine Isaac <aisaac@few.vu.nl
> > > > [mailto:aisaac@few.vu.nl] > wrote:
> > > 

> > > > > Hi Jodi,
> > > 

> > > > >
> > > 

> > > > > I think I have not much to add to your remarks--they seem all right.
> > > 

> > > > >
> > > 

> > > > > The exception being perhaps SEO. This is a feature that may be part of
> > > > > many
> > > 

> > > > > other use cases. Like Bibliographic data, Archive and heterogeneous
> > > > > data.
> > > 

> > > > > Perhaps another instance of a case that can belong to several
> > > > > clusters.
> > > 

> > > > > Cluster curators, feel free to pick it up if you think it is also
> > > 

> > > > > interesting for you!
> > > 

> > > >
> > > 

> > > > You're right, but I think it needs to be handled separately if we
> > > 

> > > > don't want it to be hidden by more complex aspects of our work.
> > > 

> > > > >
> > > 

> > > > > Antoine
> > > 

> > > > >
> > > 

> > > > >
> > > 

> > > > >> Perhaps "Social & Search" is the cluster that's left?
> > > 

> > > >
> > > 

> > > > +1
> > > 

> > > >
> > > 

> > > > >>
> > > 

> > > > >> * Use Case Ranking Search Results by Popularity using Circulation
> > > > >> Data
> > > 

> > > > >> <http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Ranking_Search_Results_by_Popularity_using_Circulation_Data>
> > > 

> > > > >> (Jodi)
> > > 

> > > > >> * Use Case SEO
> > > > >> <http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_SEO>
> > > 

> > > > >> * (pending use case -- "Use Case Link Social Bibliography to a
> > > 

> > > > >> Bibliographic Network")
> > > 

> > > > >>
> > > 

> > > > >>
> > > 

> > > > >> I think this is archival data (though it isn't heterogeneous):
> > > 

> > > > >>
> > > 

> > > > >> * Use Case NLL Digitized Map Archive
> > > 

> > > > >> <http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_NLL_Digitized_Map_Archive>
> > > 

> > > > >> (William)
> > > 

> > > >
> > > 

> > > > I think it would fit better in Digital Objects (it's not to get rid of
> > > > it ;-)
> > > 

> > > > >>
> > > 

> > > > >>
> > > 

> > > > >> I tentatively added "finding items/collection-level description",
> > > > >> though
> > > 

> > > > >> it could use a better name, for these:
> > > 

> > > > >>
> > > 

> > > > >> * Use Case Find materials in the closest physical collection
> > > 

> > > > >> <http://www.w3.org/2005/Incubator/lld/wiki/index.php?title=Use_Case_Find_materials_in_the_closest_physical_collection&action=edit&redlink=1>
> > > 

> > > > >> (Gordan/Jodi to write in January)
> > > 

> > > > >> * Use Case Find e-books or other digital materials, according to
> > > > >> access
> > > 

> > > > >> restrictions
> > > 

> > > > >> <http://www.w3.org/2005/Incubator/lld/wiki/index.php?title=Use_Case_Find_e-books_or_other_digital_materials,_according_to_access_restrictions&action=edit&redlink=1>
> > > 

> > > > >> (Gordan/Jodi to write in January)
> > > 

> > > > >>
> > > 

> > > > >> * Use Case Library Address Data
> > > 

> > > > >> <http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Library_Address_Data>
> > > 

> > > > >> (Gordon)
> > > 

> > > > >>
> > > 

> > > > >>
> > > 

> > > > >> Maybe someone else can come up with a better way to cluster these?
> > > 

> > > >
> > > 

> > > > Just another proposal for the name of the cluster : can't we use the
> > > 

> > > > "Obtain" user task from FRBR ?
> > > 

> > > >
> > > 

> > > > Cheers
> > > 

> > > > Emma
> > > 

> > > >
> > > 

> > 
> > 

>