Availability API (was: Jangle: Why such an emphasis?)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Availability API (was: Jangle: Why such an emphasis?)

Jakob Voss-4
Hi,

A colleauge just pointed me to this discussion. Ross Singer wrote:

>> But even exposure is going to harder that people think.  Like when we
>> were talking about Get Availability in the ils-di group. It's not
 >> necessarily binary.  It's much more complex based on the circulation
 >> policy definitions of a system. Even within 2 SirsiDynix Unicorn or
 >> Symphony systems, it  could be two different responses.  The mapping
 >> of that is going to have to be custom unless we just use verbatim what
 >> we get out of the XML output, but that is going to be gibberish to
 >> the user because in many cases it is just a policy name.
>>
> Well, here I disagree.  Availability _is_ inherently binary.  At least
> at the 5,000 ft. view a discovery system cares about.  Is this thing
> in a place that it can be used or is it in somebody's trunk or lost or
> at the bindery?  Whatever the local status code is is useful, but
> ultimately they're all just saying "yes, it's around somewhere" or
> "no, sorry, try again later".

The many availability status come from librarians that tried to encode
all *their* information needs instead of first supporting the users
information needs and thinking about additional complexity afterwards. I
fully agree that availability is inherently binary but this does not
forbid more complex cases as long as they can be mapped to a binary value.

I have not found the current status of availability schema in Jangle
(and I will go on vacation tomorrow so I cannot dig into this month),
but maybe you are interested in my current work [1] on a simple
availability API. In the end you query for an information object by ID
and get a binary value whether it is available for one of the following
services:

* "presentation" - the item can be used inside the institution (in their
rooms, in their intranet etc.)

* "loan"- the item can be used outside of the institution (by lending or
online access)

* "interloan" - the item can be used mediated by another institution.
That means you do not have to interact with the institution that was
queried for this item. This include interlibrary loan as well as public
online ressources that are not hosted or made available by the queried
institution.

In my opinion it makes no sense to encode librarian views like the
difference between digital and physical into availability - you just
what to know "can I get this book/article/film/etc."?

> Realistically, in your own library, you should know what the local
> nuances are so you can present actions like "recall" or "hold", but I
> think it's out of scope for Jangle.  Actually, I know it is.  Jangle
> will return whatever you've got - it's up to a client application to
> make sense of it.

You *can* add availability nuances as long as they are clearly defined
and not mandatory. For instance you could encode the information that a
book will be back in 10 days this way ("P10D" is ISO 8601 by the way):

<availability service="loan" available="false" delay="P10D"/>

but for the basic clients it is just

<availability service="loan" available="false" />

Or a special book from the rara collection that can only be viewed in
the library after registering one day before:

<availability service="presentation" available="true" delay="P1D">
  <limitation type="permit"/>
  <message lang="en">Please register at the information desk to view
this book in our rooms at the next day.</message>
</availability>

If the library thinks that 1 day delay is normal, then for the basic
client it is just

<availability service="presentation" available="true"/>

A more intelligent client can also display the information how long you
have to wait and a simple client can just display the binary value.

There is no problem in encoding complex things as long as you start with
the most simple and frequent generalization. I think it is a good idea
to include at least some availability details in Jangle. Elsewise people
will start to add their nuances in non-standard ways and Jangle does not
really help to ensure interoperability. But people will use their own
ways to encode data without respecting standards anyway, won't they? ;-)

Greetings,
Jakob Voss

[1] See
http://www.gbv.de/wikis/cls/Document_Availability_Information_API for
notes and http://ws.gbv.de/daia/daia.xsd for a schema draft.

--
Jakob Voß <[hidden email]>, skype: nichtich
Verbundzentrale des GBV (VZG) / Common Library Network
Platz der Goettinger Sieben 1, 37073 Göttingen, Germany
+49 (0)551 39-10242, http://www.gbv.de

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Availability API (was: Jangle: Why such an emphasis?)

Ross Singer-2
Hi Jakob,

On Thu, Jul 10, 2008 at 4:23 AM, Jakob Voss <[hidden email]> wrote:

> The many availability status come from librarians that tried to encode all
> *their* information needs instead of first supporting the users information
> needs and thinking about additional complexity afterwards. I fully agree
> that availability is inherently binary but this does not forbid more complex
> cases as long as they can be mapped to a binary value.
>

I completely agree with this statement.  There are levels of
information needed for different clients which has different
expectations of what to do with the responses.

This is the failing (in my mind) of NCIP.  There was an implicit
belief that every application cared about the most granular of details
between user and item and allowed for a vast array of possibilities.

When really you just want to know if it's accessible and where.

> I have not found the current status of availability schema in Jangle (and I

Nothing is mandated in Jangle.  Currently it's only using the DLF
ExpandedRecords simpleAvailability schema because it's, well,
dead-simple.

In theory, you could have MFHD or ISO 20775 or use your simple
availability response.

The DLF's is *too* simple (i.e. it scales down just fine, but it
doesn't scale up like your API does).  It only offers "Yes, no,
maybe", a local status message and, if unavailable, a timestamp as to
when it will return.

> will go on vacation tomorrow so I cannot dig into this month), but maybe you
> are interested in my current work [1] on a simple availability API. In the
> end you query for an information object by ID and get a binary value whether
> it is available for one of the following services:
>
> * "presentation" - the item can be used inside the institution (in their
> rooms, in their intranet etc.)
>
> * "loan"- the item can be used outside of the institution (by lending or
> online access)
>
> * "interloan" - the item can be used mediated by another institution. That
> means you do not have to interact with the institution that was queried for
> this item. This include interlibrary loan as well as public online
> ressources that are not hosted or made available by the queried institution.
>

Getting back to the NCIP problem, doesn't this level of specificity
get into requiring some knowledge about the person who is asking?

> In my opinion it makes no sense to encode librarian views like the
> difference between digital and physical into availability - you just what to
> know "can I get this book/article/film/etc."?
>

This is what I'm screaming.

>
> You *can* add availability nuances as long as they are clearly defined and
> not mandatory. For instance you could encode the information that a book
> will be back in 10 days this way ("P10D" is ISO 8601 by the way):

The DLF does something similar, they just use the full datetimestamp a
la ISO 8601.

>
> <availability service="loan" available="false" delay="P10D"/>
>
> but for the basic clients it is just
>
> <availability service="loan" available="false" />
>
> Or a special book from the rara collection that can only be viewed in the
> library after registering one day before:
>
> <availability service="presentation" available="true" delay="P1D">
>  <limitation type="permit"/>
>  <message lang="en">Please register at the information desk to view this
> book in our rooms at the next day.</message>
> </availability>
>

Well, this is nice and simple :)  Just to be clear, what would, say,
an electronic journal's availability look like?

Have you considered proposing this to the DLF ILS-DI group?  I doubt
their schema is carved in stone.

> There is no problem in encoding complex things as long as you start with the
> most simple and frequent generalization. I think it is a good idea to
> include at least some availability details in Jangle. Elsewise people will
> start to add their nuances in non-standard ways and Jangle does not really
> help to ensure interoperability. But people will use their own ways to
> encode data without respecting standards anyway, won't they? ;-)
>

Again, I still think this is outside the scope of Jangle.  Jangle is
just 'exposing resources', it's not dictating how those resources
should be formatted.

That's not to say I don't think some agreements or conventions should
be made regarding how data should be returned (perhaps through
community profiles), but the spec itself isn't going to explicitly say
that a Jangle'd system must return MARCXML, vCard, ISO 20775, etc.
because it's going to vary a lot from backend system to backend system
(remembering that Jangle isn't exclusive to ILSes).

-Ross.

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Availability API

Jakob Voss-4
Hi Ross,

> This is the failing (in my mind) of NCIP.  There was an implicit
> belief that every application cared about the most granular of details
> between user and item and allowed for a vast array of possibilities.

And there was no simple documentation and open source implementation of
NCIP as far as I know - if you can just start with an existing
implementation of the API it is much easier than having to dig into all
details of the standards to start with.

>> * "presentation" - the item can be used inside the institution (in their
>> rooms, in their intranet etc.)
>>
>> * "loan"- the item can be used outside of the institution (by lending or
>> online access)
>>
>> * "interloan" - the item can be used mediated by another institution. That
>> means you do not have to interact with the institution that was queried for
>> this item. This include interlibrary loan as well as public online
>> ressources that are not hosted or made available by the queried institution.
>
> Getting back to the NCIP problem, doesn't this level of specificity
> get into requiring some knowledge about the person who is asking?

You *always* need some knowledge of the context. Availability is no
inherent property of an item. You can only talk about availability of a
given service in a given context. The person who is asking is part of
the context - you have to agree upon the context before you can ask for
availability status.

  >> You *can* add availability nuances as long as they are clearly
defined and

>> not mandatory. For instance you could encode the information that a book
>> will be back in 10 days this way ("P10D" is ISO 8601 by the way):
>
> The DLF does something similar, they just use the full datetimestamp a
> la ISO 8601.
>
>> <availability service="loan" available="false" delay="P10D"/>
>>
>> but for the basic clients it is just
>>
>> <availability service="loan" available="false" />
>>
>> Or a special book from the rara collection that can only be viewed in the
>> library after registering one day before:
>>
>> <availability service="presentation" available="true" delay="P1D">
>>  <limitation type="permit"/>
>>  <message lang="en">Please register at the information desk to view this
>> book in our rooms at the next day.</message>
>> </availability>
>
> Well, this is nice and simple :)  Just to be clear, what would, say,
> an electronic journal's availability look like?

If the journal can only be read in the intranet of the library, is it

<availability service="presentation" available="true"/>

If you can read it online with you library account, it is

<availability service="loan" available="true"/>

Either you lend a physical item or access a digital item - the important
aspect of availability is to be able to use it at your place.

If the journal is open access it could be

<availability service="loan" available="true"/>
<availability service="interloan" available="true"/>

So you can get it via the library but also without having to be a member
of the library.

I shortly talked with Janifer Gatenby about the ISO 20775 holdings
schema, I think the mapping between ISO holdings and my simple
availability services (daia) is

ISO status <=> daia status
"reference lookup" <=> "presentation"
"loan" or "online access" <=> "loan"
"digital copy" or "physical copy" <=> "interloan"

> Have you considered proposing this to the DLF ILS-DI group?  I doubt
> their schema is carved in stone.

Maybe after my vacation :-)

Greetings,
Jakob

--
Jakob Voß <[hidden email]>, skype: nichtich
Verbundzentrale des GBV (VZG) / Common Library Network
Platz der Goettinger Sieben 1, 37073 Göttingen, Germany
+49 (0)551 39-10242, http://www.gbv.de

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: Availability API

Tim McGeary
I had started an email late yesterday (that I never finished) about the
need for availability to be non-binary, but today decided to wait on
finishing it after reading Ross and Jakob's latest emails in the
conversation.  Instead I started a new one here.

I'm intrigued by the service element in the availability, and I'd to
focus on that more, because I think that might be the bridge between
what I was originally going to write as support for non-binary
availability and what you are talking about now.

My original point was that making availability only binary does a
disservice to users and does not taking into considerations of the
librarianship involved in developing circulation and cataloging policies
of items.  If we want to build ILS discovery interfaces, then we best be
prepared to discovery everything necessary to connect the patron to the
items they are searching for.  Understanding or allowing the unique
elements of circulation maps and policies is part of that.

What this means is that often a second step is required despite whether
the item is Available or Unavailable to connect the user with the actual
item.  The current OPACs have been doing this disservice, too, and that
is why I wholeheartedly believe new discovery interfaces ought to place
high importance of the missing steps.

Examples of this are restrictions upon available, such as:
   * - locations physical items can be used (rare book room, reference
room, specific library building).  This doesn't require a second step,
but the location may not tell you the restrictions, and "Available" to a
user is assumed that I can check this book out, which is not true.

   * - time period items can be borrowed - perhaps a book is about to be
on reserve, thus not allowing for circulation.  In cases where borrowing
periods are less than normal, a second step to place an ILL request
should be given, passing on the item information via OpenURL to the ILL app.

   * - items that are available, but in storage.  This is becoming more
and more prevalent in libraries as shelf space becomes a premium.  And
some items in storage can circulate while others cannot.  Often this
requires a second step of placing a request to a different system.  This
circulation rule should be able to happen in an ILS-DI.

More importantly, simply displaying unavailable is a disservice because
there are many options to still obtain the item being searched, such as
recalling the item (which may or may not be based on user privileges),
requesting it through ILL.  The item may be lost or missing, in which
case a request for ILL or re-purchase could be offered to the patron.

My point is that simply reporting available or not available does not,
in any way, do the job of getting the user to an item.  Circulation
policies, however, are designed to give the user as much information as
possible about item's available and usability, and a binary display
thwarts this effort.

But now I wonder if the service element of your conversation would solve
this problem.  I think that the three options you are discussing are
still too minimal to cover all bases, but it's definitely a start.  Can
we elaborate on these options?

I disagree that you need to know who the user is to understand the
context of the item.  The privilege of using of the item is certainly
defined by the context of the user, but the actual context of an item's
availability is not defined by that.  Just because one user may not have
the privilege of circulating that item does not make it unavailable.

Tim

Tim McGeary
Senior Systems Specialist
Lehigh University
610-758-4998
[hidden email]
Google Talk: timmcgeary
Yahoo IM: timmcgeary

Jakob Voss wrote:

> Hi Ross,
>
>> This is the failing (in my mind) of NCIP.  There was an implicit
>> belief that every application cared about the most granular of details
>> between user and item and allowed for a vast array of possibilities.
>
> And there was no simple documentation and open source implementation of
> NCIP as far as I know - if you can just start with an existing
> implementation of the API it is much easier than having to dig into all
> details of the standards to start with.
>
>>> * "presentation" - the item can be used inside the institution (in their
>>> rooms, in their intranet etc.)
>>>
>>> * "loan"- the item can be used outside of the institution (by lending or
>>> online access)
>>>
>>> * "interloan" - the item can be used mediated by another institution. That
>>> means you do not have to interact with the institution that was queried for
>>> this item. This include interlibrary loan as well as public online
>>> ressources that are not hosted or made available by the queried institution.
>> Getting back to the NCIP problem, doesn't this level of specificity
>> get into requiring some knowledge about the person who is asking?
>
> You *always* need some knowledge of the context. Availability is no
> inherent property of an item. You can only talk about availability of a
> given service in a given context. The person who is asking is part of
> the context - you have to agree upon the context before you can ask for
> availability status.
>
>   >> You *can* add availability nuances as long as they are clearly
> defined and
>>> not mandatory. For instance you could encode the information that a book
>>> will be back in 10 days this way ("P10D" is ISO 8601 by the way):
>> The DLF does something similar, they just use the full datetimestamp a
>> la ISO 8601.
>>
>>> <availability service="loan" available="false" delay="P10D"/>
>>>
>>> but for the basic clients it is just
>>>
>>> <availability service="loan" available="false" />
>>>
>>> Or a special book from the rara collection that can only be viewed in the
>>> library after registering one day before:
>>>
>>> <availability service="presentation" available="true" delay="P1D">
>>>  <limitation type="permit"/>
>>>  <message lang="en">Please register at the information desk to view this
>>> book in our rooms at the next day.</message>
>>> </availability>
>> Well, this is nice and simple :)  Just to be clear, what would, say,
>> an electronic journal's availability look like?
>
> If the journal can only be read in the intranet of the library, is it
>
> <availability service="presentation" available="true"/>
>
> If you can read it online with you library account, it is
>
> <availability service="loan" available="true"/>
>
> Either you lend a physical item or access a digital item - the important
> aspect of availability is to be able to use it at your place.
>
> If the journal is open access it could be
>
> <availability service="loan" available="true"/>
> <availability service="interloan" available="true"/>
>
> So you can get it via the library but also without having to be a member
> of the library.
>
> I shortly talked with Janifer Gatenby about the ISO 20775 holdings
> schema, I think the mapping between ISO holdings and my simple
> availability services (daia) is
>
> ISO status <=> daia status
> "reference lookup" <=> "presentation"
> "loan" or "online access" <=> "loan"
> "digital copy" or "physical copy" <=> "interloan"
>
>> Have you considered proposing this to the DLF ILS-DI group?  I doubt
>> their schema is carved in stone.
>
> Maybe after my vacation :-)
>
> Greetings,
> Jakob
>

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech