Re: Holdings-as-Offer: wrap-up

Dan, the example I had in mind was a little different. Let's say that 
the catalog is for TinyTown Public Library. The display of the holdings is:

Reference    876.54   Library use only

Nothing in that indicates the actual library. Another case is for 
electronic materials. Library systems handle this differently, but there 
isn't a location in many cases:

Online    Click here

I'm thinking that there are cases in which the library itself is not 
included in the holdings statement (or anywhere else on the page) 
because it is inherent in the context of the system being searched. So 
my question is whether there is value in including information about the 
library itself as a super-location to the holdings location, or is the 
assumption that this connection will be made through, e.g., the URL of 
the web page that has the markup?

I think my question leads to a broader one about the use case for 
library data in schema.org. When I look at product examples it is clear 
to me that the target is the URL of the product page. Is this also the 
assumption for library data in schema.org -- that we are expecting a 
search engine retrieval of a page for a library resource, and that page 
is the target of the search? If so, then that URL is all that is needed 
to link to the library and its resource. If, however, we anticipate 
other uses to be made of the schema mark-up, such as organizing 
retrieved items by geographical location, then we need to get that 
information into each web page. This may be unrelated to the markup of 
holdings, but it was this proposal that brought it to mind.

kc

On 10/18/13 9:37 AM, Dan Scott wrote:
> 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
>>
>

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

Received on Friday, 18 October 2013 18:12:42 UTC