Re: Changes vs. new element

On Thu, Aug 1, 2013 at 11:22 AM, Wallis,Richard <Richard.Wallis@oclc.org> wrote:

> I agree that the reverse connecting property from Offer to an
> Organization/Library (seller) is not appropriately named - maybe we could
> suggest adding 'lender'.

Or deprecate "seller" and make "offerer" the preferred generic
attribute (kind of kidding, but kind of not; "offerer" is a horrible
name, but it does avoid the specifics of selling/lending/giving
away...)

On holding statements: I agree with approaching "holding statements"
(in particular for serials) separately. Sadly, I think it's going to
be challenging for many library systems to do much more than offer up
a Text attribute.

> As to the shelf location, call number, availability information.  Would
> this not sit best on IndividualProduct alongside serialNumber (barcode)?
> How abut 'storageLocation' and 'locationReference' as properties for
> these?  The IndividualProduct bing referenced from an Offer as
> 'itemOffered'.

Hmm. Wouldn't this require IndividualProduct to then mirror all of the
Offer properties? That seems non-optimal.

http://schema.org/Offer shows examples where the Offers are simply
embedded within the containing Product or (for example 3) Book -
suggesting that there's no need for the itemOffered attribute to be
used on Offer, unless it's linking from a different context. This is
why I modelled individual-holdings-based-on-Offer the way that I did.

If we wanted to put forth a LibraryOffer class that simply subclasses
Offer but provides more library-specific attribute names &
definitions, we could... but that would then be quite
library-specific, and wouldn't be usable by (say) book sellers or
publishers.

I think we should simply propose a generalization of some of the
definitions and use Offer directly.

Received on Thursday, 1 August 2013 16:06:30 UTC