- From: Wallis,Richard <Richard.Wallis@oclc.org>
- Date: Mon, 5 Aug 2013 14:14:32 +0000
- To: Owen Stephens <owen@ostephens.com>
- CC: "public-schemabibex@w3.org" <public-schemabibex@w3.org>, Karen Coyle <kcoyle@kcoyle.net>, Dan Scott <denials@gmail.com>, Alf Eaton <eaton.alf@gmail.com>
Interesting idea, worth thinking through - once we have the basic pattern for holdings nailed down ;-)
Giving a textual description for a 'accessRequirements' property would be not that difficult. However, enabling the machine readability would be a challenge.
A way to describe the need for a Netflix account or library membership or ip address range would need to reference things that as yet, I believe, have not been mapped into Schema.
Things that are concerns much wider than the bib domain. I suspect that this may be best approached from the GoodRelations area.
~Richard.
On 5 Aug 2013, at 14:04, Owen Stephens <owen@ostephens.com> wrote:
> Dan pointed at a discussion in this area from the tail end of last year, so I thought I'd resurrect something I said at that time, which was along the lines of wondering whether we should have a way of describing the characteristics of those that can typically make use of a service or resource.
>
> So a resource might only be accessible by a user using a device with an IP address in a certain range... or with a certain membership (only members of the library can access this resource) ... or with a certain authentication mechanism ... or with a personal subscription to a service etc.
>
> This would seem useful in human readable terms when describing things ('this film is accessible to someone with a Netflix subscription', 'this item is accessible to someone who is a member of this library'), and also in machine readable terms - opening up the possibility of a service being able to combine the characteristics required for access with what it knows of a person to work out whether they should/are likely to be able to access the resource.
>
> For me the acid test is a non-library scenario - the netflix/hulu usecase - given a tv programme/film of music I'd really like to know whether I can already access it as a Netflix/Hulu subscriber. I think this is essentially the 'appropriate copy' scenario OpenURL was designed to work with. If we can find a way of expressing this then it feels like it definitely has applicability outside the library sphere.
>
> Any takers?
>
> Owen
>
> Owen Stephens
> Owen Stephens Consulting
> Web: http://www.ostephens.com
> Email: owen@ostephens.com
> Telephone: 0121 288 6936
>
> On 2 Aug 2013, at 08:19, Alf Eaton <eaton.alf@gmail.com> wrote:
>
>> On 1 August 2013 20:03, Karen Coyle <kcoyle@kcoyle.net> wrote:
>>>
>>>
>>> On 8/1/13 11:05 AM, Dan Scott wrote:
>>>
>>>>
>>>> If I can be permitted to fantasize about a library scenario for a
>>>> moment, if the search engine recognized via your location or IP
>>>> address that you were in or near a library, it could serve as your
>>>> library catalogue and display the additional metadata when it was
>>>> actually useful to you (much as it detects when you're looking up
>>>> movies, it can show you the local movie listings, including name &
>>>> address of the theatre, immediately rather than forcing you to click
>>>> through).
>>>
>>>
>>> That was my first fantasy as well. See:
>>>
>>> http://kcoyle.blogspot.com/2012/09/rich-snippets.html
>>
>> That's kind of what Google Scholar does
>> <https://www.google.com/intl/en/scholar/libraries.html>: IP address
>> ranges and library serials holdings => appropriate links to article
>> full text through the library resolver, when the library has access.
>> It's particularly annoying that - as far as I know - libraries only
>> publish this holdings file to Google, rather than making it available
>> for everyone.
>>
>> Keeping up-to-date with availabililty of particular items would be too
>> much for a crawler, as it changes too quickly, so there would need to
>> be a push API, like there is for Google Shopping
>> <https://developers.google.com/shopping-content/>, updated with every
>> availability change. Alternatively, as long as the library can resolve
>> an OpenURL query, tools like <http://www.libraryextension.com/> can
>> look up availability of single items on demand.
>>
>> So, my fantasy would be:
>>
>> a) a rel="holdings" link from the front page of every library to a
>> paginated HTML list of all the library's holdings, marked up with
>> microdata (and/or a paginated JSON-LD feed, as a bonus).
>>
>> b) a rel="openurl" link from the front page of every library that
>> points to the root of an OpenURL resolver, which would resolve queries
>> to a single page marked up with availability information as microdata
>> (and/or a JSON-LD item, as a bonus).
>>
>> Alf
>>
>
>
>
Received on Monday, 5 August 2013 14:15:39 UTC