Re: Changes vs. new element

Hi,

I'm also in favour ofgeneralizing offer.

*But* getting schema.org accept to change a property name like "seller" is going to be tricky. This is actually the identifier of the property, so if you change it, you can break existing data.
What is possible is to keep the existing identifier, but add a caveat in the definition / scope note.
Alternatively, if this is not satisfactory, we could ask to add a new property at the level of Offer: "freeOfferer" or something like that.

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.

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.
>

Received on Thursday, 1 August 2013 16:25:57 UTC