Re: Holdings - was Re: Some additions to wiki

Corey, I added your example to the web page, but damn you for reminding 
us about serials! :-)

http://kcoyle.net/holdings.html

kc

On 1/14/13 8:49 AM, Corey Harper wrote:
> 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
>>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Tuesday, 15 January 2013 05:34:44 UTC