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

On Mon, Aug 5, 2013 at 9:04 AM, 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?

Hi Owen:

I agree, this would be really useful. Indeed, when I initially dove
into holdings as pure Offers [1], I said:

"""Holdings often list electronic resources, as well. If so, I map
them to a http://schema.org/Offer and make the
http://schema.org/ItemAvailability enumeration using
http://schema.org/OnlineOnly. There is some potential for using the
http://schema.org/Offer eligibleCustomerType property to identify
whether a given electronic resource is publicly available, or
restricted to library patrons (or a particular subset of library
patrons) via proxy access or the like."""

However, pulling on that thread a bit more, the eligibleCustomerType
has to be a BusinessEntityType, which in turn is an enumeration.
There's no direct mapping here to something like "enduser who is a
member of Organization X" or "enduser who is a subscriber to Service
Y". So this may be a dead end, unless I'm misunderstanding the
limitations of enumerations, or we can convince the GoodRelations
group that there's a need for more info here.

In the short term, I suppose you could implicitly rely on the content
of the <link> node that describes the eligible Customer Type:

<div itemscope itemtype="http://schema.org/Offer">
  <link itemprop="eligibleCustomerType"
href="http://purl.org/goodrelations/v1#Enduser">Available to Netflix
subscribers</link>
  ...
 </div>

(It worries me a bit that <link> is supposed to be an empty element,
but http://schema.org/MedicalGuideline uses this pattern, so there's
some precedent for its use here...)

But in the longer term, being able to assert "requiresMembershipIn"
and pointing that property (whether at the Offer level, or as a
refinement of eligibleCustomerType) at an Organization might be quite
valuable.

In addition... MediaObject has a requiresSubscription property, which
is a Boolean. So for the Netflix scenario, you could also use the
MediaObject property, and set that Boolean flag. A subscription can be
either paid or free, so taken broadly, a membership to a library might
be an acceptable fit for, say, describing Overdrive downloads or IP
address restrictions. However, it doesn't give you the ability to
identify _what_ subscription is required, so we're back to needing a
refinement to eligibleCustomerType or a new "requiresMembershipIn"
property. And I agree with Richard that this requirement goes well
beyond libraries or the bibliographic domain.

1. http://lists.w3.org/Archives/Public/public-schemabibex/2013Jul/0068.html

Received on Monday, 5 August 2013 15:19:29 UTC