- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 14 Jan 2013 06:17:10 -0800
- To: Richard Wallis <richard.wallis@oclc.org>
- CC: public-schemabibex@w3.org
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 14:17:51 UTC