Re: Holdings-as-Offer: wrap-up

Hi Karen:

In the existing examples, I've pointed "seller" at a Text value as
that was the most expedient method for the purposes of markup, but as
the range of "seller" includes "Organization" (and by virtue of that,
"Library"), it was implied that one could point at or inline a full-on
Library type. Perhaps we should include one or more examples like the
following for the purposes of clarity:

<div>Library: <span itemprop="seller" itemscope
itemtype="Library"><span itemprop="name">Example Branch
1</span></span></div>

If we go this route, of course all of the properties for Library could
be inlined like openingHours, etc, but more realistically we would
want to use a URL to fully describe the Library. I do eventually hope
to do this for Evergreen, as we store hours of operation, email
address, physical address, phone number, etc for each library... just
haven't got there yet.

Dan

On Fri, Oct 18, 2013 at 11:49 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:
> Thanks, Dan. I'm wondering about the Library as Seller, and if there isn't a
> case to be made to also/instead include http://schema.org/Library. I'm fine
> with availableAtOrFrom for the holding location, but it seems that we are
> missing the information about the library itself as a location. This may not
> appear as such in library catalogs because, well, you are in that library's
> catalog so it's a given.
>
> I realize that this is a bit fuzzy because holding locations can be branches
> of a library system, which are schema.org/Library(s) in their own right.
> However, a holding location could also be something like "Reference" so the
> identity of the library as local business (which is where it is in schema)
> is not explicit.
>
> ?? other thoughts?
>
> kc
>
>
> On 10/18/13 7:25 AM, Dan Scott wrote:
>>
>> Hi all:
>>
>> Thanks so much for your patience and contributions over the past few
>> months on the Holdings-as-Offer recommended usage document at
>> http://www.w3.org/community/schemabibex/wiki/Holdings_via_Offer
>>
>> I spent some time after our call yesterday tweaking the document to
>> better reflect some of our rationale for the property mappings that
>> came up during our discussions (both on list and via calls). My hope
>> is that the target audience will be able to efficiently follow the
>> "What? That's weird... Oh, I get it!" path that we've travelled to
>> arrive here. (Okay, I admit, future-me is likely part of that target
>> audience.)
>>
>> I've added suggested mappings for various item statuses that had until
>> now been buried in the examples, so we can support both the
>> likes-to-read-the-doc and the quick-copy-and-paste audience.
>>
>> But I do have one last question. The rationale I gave for marking up
>> "Shelving location" as "description" rather than "availableAtOrFrom"
>> as the range of the latter property is "Place", and as a shelving
>> location is really just a subsection of a Place, we would need to use
>> the Place->containedIn->Place if we wanted to be formal about the
>> markup.
>>
>> However, I'm now thinking that we should relax, take advantage of
>> schema.org's pragmatic nature here, and go with "availableAtOrFrom"
>> anyway, with the expectation that most of the time it will simply be a
>> Text value like "Stacks", "3rd floor - Reference", or "Kids", while
>> still supporting the formal range of Place. The advantage of
>> "availableAtOrFrom" is that it would give the attribute a tighter
>> scope than "description" and processors would be able to glean more
>> meaning when they run across it.
>>
>> +1 / -1 to recommending "availableAtOrFrom" as a mapping for "shelving
>> location"?
>>
>>
>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet
>

Received on Friday, 18 October 2013 16:38:15 UTC