RE: Holdings and Access criteria (was Changes vs. new element)

I'm up for a try. Here's a brief mockup for an offer for "The Avengers" through Netflix:

<http://www.worldcat.org/oclc/798373235>
	a schema:Movie;
	schema:name "The Avengers";
	schema:datePublished "2012"^^xsd:date;
	schema:sameAs <http://en.wikipedia.org/wiki/The_Avengers_%282012_film%29>;
	.

<http://movies.netflix.com/WiPlayer?movieid=70217913>
	a schema:Offer;
	schema:seller <http://dbpedia.org/resource/Netflix>; 
	schema:itemOffered <http://www.worldcat.org/oclc/798373235>;
	.

Jeff

> -----Original Message-----
> From: Shlomo Sanders [mailto:Shlomo.Sanders@exlibrisgroup.com]
> Sent: Monday, August 05, 2013 9:07 AM
> To: Owen Stephens; public-schemabibex@w3.org
> Cc: Karen Coyle; Dan Scott; Alf Eaton
> Subject: RE: Holdings and Access criteria (was Changes vs. new element)
> 
> Nice
> 
> Thanks,
> Shlomo
> 
> Experience the all-new, singing and dancing interactive Primo brochure
> 
> 
> -----Original Message-----
> From: Owen Stephens [mailto:owen@ostephens.com]
> Sent: Monday, August 05, 2013 16:04
> To: public-schemabibex@w3.org
> Cc: Karen Coyle; Dan Scott; Alf Eaton
> Subject: Holdings and Access criteria (was Changes vs. new element)
> 
> 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:29:55 UTC