Re: Holdings - was Re: Some additions to wiki

I agree with all of this about holdings, in principle, but I also
worry that there are some aspects of our data that will be hard to
capture without treating "holding" as an entity rather than--or in
addition to--a relationship.

My instincts tell me that we have an "instance" or "item" type, which
then has a relationship to a library or other institution. This works
fine for classifications, physical condition & preservation notes,
etc, but falls short with serials, right? Unless we define our "items"
as being either individuals or arbitrary sets/groups. Then, we could
say that the serial "Nature" has a print "instance" related to (held
by) NYU with such & such a call # and this *summary* of holdings, and
an electronic instance with a different summary of holdings as well as
relationships to NYU (by subscription), and a provider of, say,
Proquest. (And in NYU's case, there are half a dozen such instances,
(Gale, Ebsco, Ovid, Nature itself, ...) all with different "holdings".
Are we comfortable defining the "physical" items as aggregations as
well as individuals, and with lumping E- into that same model?

-Corey

On Mon, Jan 14, 2013 at 9:17 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:
> Richard, I'm grabbing some screen shots of library holdings displays so we
> can look at them together. I'll just pop them onto a web page.
>
> sku is a product code, not a code for an individual item. ISBN is a sku.
> Libraries do add a barcode to items for checkout, and it acts like a sku,
> only it's at an item level. The call number is something else, because it
> can contain location information. ("Fiction") I think the examples will make
> it all more clear.
>
> kc
>
>
> On 1/14/13 5:50 AM, Richard Wallis wrote:
>>
>> Would not 'sku' in http://schema.org/Offer serve this purpose.
>>
>> I'm thinking of a CreativeWork for the bib stuff, and SomeProducts for the
>> manifestation level stuff linked using Offer to a Library - the offer sku
>> providing somewhere for [what us library folks call] the call number and
>> businessFunction for the types of things you can do with the item in
>> question.
>>
>> ~Richard.
>>
>> On 14/01/2013 13:23, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
>>
>>> Richard, I agree that "holdings" is hard to model as a thing. "Name" for
>>> the organization is already included, as is location of the
>>> organization. So far there is no "location" for the individual product
>>> ("call number" in libraries) since other businesses do not provide
>>> locations for individual items. In fact, there is very little item-level
>>> information so far in schema. Libraries will need that for call number
>>> (which is supposed to be unique within the library and to provide a
>>> single place for each book -- although this isn't followed 100% in all
>>> libraries), and the availability of individual items. So perhaps what we
>>> should model is an item level.
>>>
>>> kc
>>>
>>> On 1/14/13 2:06 AM, Richard Wallis wrote:
>>>>
>>>> Hi Karen,
>>>>
>>>> Holdings is a difficult one. I have trouble in justifying, in data
>>>> modelling terms, its existence as an an entity. Here is most of an
>>>> email, in another thread I am in, on the subject.
>>>>
>>>>      I still remain to be convinced that a Holding is a thing to be
>>>>      modelled as an entity in its own right.
>>>>
>>>>      Surely the realisation of a holding is just the relationship
>>>> between
>>>>      a thing (Book, Journal, License to access) and a location (Shelf,
>>>>      Library, Institution).  Its not a thing or a concept.
>>>>
>>>>      Schema, which would probably best describe an item the union
>>>> between
>>>>      a CreativeWork and a Product.  The SomeProducts[1] subtype of
>>>>      Product has the inventoryLevel property. That's what holdings are,
>>>> a
>>>>      count of the number of items at a location.
>>>>
>>>>      Trying to model, the phantom echo of performance enabling RDBMS
>>>>      denormalization in to a table called Holdings, is definitely a bad
>>>>      idea.
>>>>
>>>>      My couple of cents..
>>>>
>>>>
>>>> I believe that those outside of the library domain have equal difficulty
>>>> in understanding too.  I know this might be a radical suggestion as
>>>> holdings have been key to water-cooler discussions in libraries for
>>>> decades.   However my linked data background has taught me to model the
>>>> real things in the real world, and I am yet to meet or pick up a
>>>> holding.
>>>>
>>>> ~Richard.
>>>>
>>>>
>>>>
>>>> On 13/01/2013 15:02, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
>>>>
>>>>> I wasn't quite sure where this went, but I added two objects to the
>>>>> object-type page [1]:
>>>>>
>>>>> - the "library" object that is under localBusiness
>>>>> - a new "library holdings" type.
>>>>>
>>>>> In each I put in some text about some new properties that might be
>>>>> needed.
>>>>>
>>>>> I also have beefed up the commonEndeavor HTML example. [2] If you wrap
>>>>> <html> around it is does actually display, although it's not very
>>>>> attractive. Just pretend that there's some nice CSS involved that fixes
>>>>> that.
>>>>>
>>>>> kc
>>>>>
>>>>>
>>>>> [1]http://www.w3.org/community/schemabibex/wiki/Object_Types
>>>>> [2]http://www.w3.org/community/schemabibex/wiki/CommonEndeavor
>>
>>
>>
>>
>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>

Received on Monday, 14 January 2013 16:49:42 UTC