Stable version of DAIA data model

[sieh...@googlemail.com]

Hi,

I noticed that the Document Availability Information API (DAIA) that I
am working on, was mentioned here and there is an early implementation
in the Jangle code repository. I just wanted to let you know that we
finished a stable version (0.5) of the DAIA data model and a binding
as XML Schema.

The conceptual model of DAIA is described at one page at
http://ws.gbv.de/daia/daiamodel.pdf. The current XML Schema is located
at http://ws.gbv.de/daia/daia.xsd and a more readable documentation at
http://ws.gbv.de/daia/daia.xsd.html. A general introduction and public
notes can be found at http://www.gbv.de/wikis/cls/DAIA. Documentation
and reference implementation is still beeing worked on, but the core -
data model and format - should be ready for recommendation.

In context of the ILS Discovery Interface Task Force (http://
diglib.org/architectures/ilsdi/ ) and its official recommendation
(revision 1.1, released in December 2008) DAIA fits to the
"GetAvailability" method (section 6.3.1). The main difference is that
availability in DAIA is modeled in particular "services" instead of
just one availability status. There are four services:

* presentation - an item can be used inside the institution (in their
rooms, in their intranet etc.)
* loan - an item can be used outside of the institution (by lending or
online access)
* interloan - an tem can be used mediated by another institution.
* openaccess - an item can be used imediately without any restrictions
by the institution

Most DAIA elements are optional so you can also implement parts of it
as long as it fits to the XML Schema.

Greetings,
Jakob Voss

[Ross Singer]

Hi Jacob,

Thanks for keeping us posted on this. Indeed I have included a DAIA
output in the demo's OpenBiblio connector (although apparently not
from the 'stable' version):

http://demo.jangle.org/openbiblio/items/?format=daia

This is, admittedly, a very simple representation of DAIA.

I will also be including a DAIA serialization in the Talis Alto
connector (which I'm currently working on) for items.

I note in your documentation that you mention that 'DAIA is not about
location', which is fine. Location is going to be desirable from a
client perspective, however.

Do you think we can come up with some agreement on how to pull in
location from some other standard and namespace it (say) into DAIA?

I guess what I'm asking for is that the development community comes up
with an agreement on how we might be best able to implement this in
practice.

Perhaps this is a way to merge DAIA and the DLF simpleavailability
specs (since DLF Expanded 1.1 includes location)? Since DAIA can be
easily mapped to DLF Expanded availability, we can use its 'services'
model coupled with DLF's simple location?

Thanks!
-Ross.

[sieh...@googlemail.com]

Hi Ross,

You wrote:

> Thanks for keeping us posted on this. Indeed I have included a DAIA
> output in the demo's OpenBiblio connector (although apparently not
> from the 'stable' version):
>
> http://demo.jangle.org/openbiblio/items/?format=daia

We have an XSLT client for DAIA that could be used to better show the
list: http://ws.gbv.de/daia/daia.xsl. There will be more clients and
visualization of DAIA as soon as our server is finished.

> I note in your documentation that you mention that 'DAIA is not about
> location', which is fine. Location is going to be desirable from a
> client perspective, however.
>
> Do you think we can come up with some agreement on how to pull in
> location from some other standard and namespace it (say) into DAIA?

We thought about opening the DAIA XML format for foreign namespaces
but unless there is a standardized XML vocabulary I hesitate to
pollute the DAIA documentation and reference implementation with bad
examples. DAIA comes with several entities that can be used as
location indicators:

1. institution - the institution that grants or knows about services
and their availability (for instance a library or library network)

2. department - an administrative sub-entitity of the institution that
is responsible for an item (for instance the specific library of an
institute at a university)

3. storage - a physical location of the item (building, stack, floor
etc.)

4. label - textual label for an item (for instance the call number)

All of these entities can consist of a simple string, a hyperlink (for
instance to a map, to the homepage etc.), and an identifier (URI). I
think this should be enough for most use cases. If you want more
detailed information on location, you can specify an identifier and
provide another API to look up detailed location information via this
identifier.

> I guess what I'm asking for is that the development community comes up
> with an agreement on how we might be best able to implement this in
> practice.

Maybe I'm too pessimistic but in my impression every library network
has its own registry of library addresses and every library has its
own way to to organize in physical and administrative subsections, so
I better avoid going into details ;-)

Greetings
Jakob

--
Jakob Voß <jakob...@gbv.de>, 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