Re: use case clustering -- "collections"

On 6 Jan 2011, at 08:28, gordon@gordondunsire.com wrote:

> 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.

They're also related. For instance:
I'm looking to obtain a reading copy, but the edition doesn't matter, and I'll accept electronic or paper formats, and prefer large print. I may have further constraints on location, etc.

This is a request for a work, limited by format (I don't want audiobooks), with format-based preferences.

>  
> 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 think it's good to distinguish these. At least a wiki page for granularity (2) is needed.

-Jodi

>  
> 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> wrote:
>>>> 
>>>> > On Fri, Dec 17, 2010 at 11:18 AM, Antoine Isaac <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
>>>> >
>>> 
>>> 
>>