Re: Changes vs. new element

I do not see Holdings as a combination of location and offer, actually.

You have a copy of a book in various branches and you want to make sure
that Users who search on the Web have a way to filter down to Library
holdings themselves.  (rather than going to Amazon and buying a dreaded
copy and not supporting their local library infrastructure.  Fine.)

Let's think of it from a User experience.

A User searches on Google for "Gone With The Wind" and they could see a
"Libraries in your area that have a copy", and then pick a particular
library that is close.

The properties that Google could index to showcase that to the User would
come from the schema.org markup.

To the User, it's an offer.  A free one.  That is offered by a particular
organization... a local branch of a library or library system.

Do you care at that point that the user has 10 other additional data
elements exposed to them on Google's search element ?  Probably not... you
just want them coming into the library.

But perhaps you have a use case that goes beyond User browsing, and want
other organizations to be able to query and crawl through "holdings"...
your then changing the context to more of a Product / Inventory scenario, I
would say and were Good Relations has some of what you need...but perhaps
not so much for the Inventory side of things.

Generalizing on Offer is the best way to approach the User experience.



On Thu, Aug 1, 2013 at 9:31 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:

> Dan Brickley replied on the vocabs list [1] to a question about changing
> existing schema.org elements:
>
> "We don't have very rigid policies. But in general, there's a strong
> bias towards additive changes, since any existing vocabulary that is
> being used is unlikely to completely vanish."
>
> This now leaves us with a bit of a dilemma for holdings. We have
> essentially two holdings proposals. One defines new elements [2], and one
> makes use of existing properties, although those would probably need to
> have their definitions expanded. [3]
>
> In addition, [2] needs a class -- either the properties would be
> sub-classed to, for example, /Library, or there needs to be a new class for
> library holdings. But /Library is a "/LocalBusiness", which is
> location-oriented and has no relation to /Offer, while library holdings is
> a kind of combination of location and offer. If we go with [3] then we
> would be re-using existing properties and classes, and the "library-ness"
> would be less evident in the holdings area (although presumably there would
> be some use of /Library in the markup).
>
> There was some positive feedback about changing /Offer so that it could be
> used for things other than sales. I'm not sure how to go about proposing
> the other changes that [3] would entail. Should we propose them en masse?
> one at a time?
>
> kc
>
>
> [1] http://lists.w3.org/Archives/**Public/public-vocabs/2013Jul/**
> 0167.html<http://lists.w3.org/Archives/Public/public-vocabs/2013Jul/0167.html>
> [2] http://www.w3.org/community/**schemabibex/wiki/Holdings<http://www.w3.org/community/schemabibex/wiki/Holdings>
> [3] http://lists.w3.org/Archives/**Public/public-schemabibex/**
> 2013Jul/0083.html<http://lists.w3.org/Archives/Public/public-schemabibex/2013Jul/0083.html>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>
>


-- 
-Thad
Thad on Freebase.com <http://www.freebase.com/view/en/thad_guidry>
Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>