Re: Changes vs. new element

On 8/1/13 9:25 AM, Antoine Isaac wrote:

>
> In the end what we submit to schema.org could be a dual proposal: we
> list 'element requirement' and for each of them we indicate what would
> be needed, either for re-use existing elements (and thus generalize
> their definition) or add new ones.
>

Thanks, Antoine, that's what I was thinking as well. It would probably 
not be an actual proposal, like our others, but more of a "preview" to 
see how the community responds to the options.

Could we do this with what we have already? I think that would mean 
adding Dan's proposal to our Holdings page. It would be nice to show the 
two side-by-side -- a kind of comparison table.

kc

> Cheers,
>
> Antoine
>
>
>
>> 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.
>>
>
>
>

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

Received on Thursday, 1 August 2013 16:42:23 UTC