[Dini-ag-kim-bestandsdaten] Re: Definition and scope of Holding

Voß, Jakob Jakob.Voss at gbv.de
Tue May 21 16:29:39 CEST 2013


Hi,

Carsten wrote:

> You suggested statuses like "ordered, in-house, in-acquisition, ready, missing".
> I think the vast majority of these statuses are statuses of a holding for a service
> and we don't come around using services and service events if we want to 
> express these statuses.

In my opinion it makes no sense to talk about "these statuses" without first
collecting a list of most relevant cases. Only in a second step one can judge
whether a status is already covered by service events, by other means, or
whether it may be wise to add another value or property for a status.

> Maybe I think too complicated. But how do you want to model those statuses 
> other than via services?

This fully depends on the actual status. For instance one might encode a status
of "being prepared at the book-binding" by adding a book-binding *location*. The
term "status" can refer to many kinds of information, so there is rarely one solution
for all status values - what status do we actually want to express?

Here is what I'm imagining:

> # An item is ordered
> :Holding dso:hasService [
>         a               dso:BuyExchangePresent ;
>         :status ssso:ExecutedService .
> ]
> 
> # An item is in acquisition 
> :Holding dso:hasService [
>         a               dso:Acquisition  ;
>         :status ssso:ExecutedService .
> ]
>
> As you can see, I added missing classes 
> "dso:BuyExchangePresent" and "dso:Acquisition " 
> assuming that they are services too.

The existing DSO services at http://gbv.github.io/dso/dso.html#classes are typically
provided by an Agent (typically a library) for a consumer (typically a patron). I don't see
how ordering or acquisition are services for a patron - they rather refer to a service 
provided by a vender for a library.

Obviously DSO lacks a service for buying a document, such as dso:Acquisition, which
could cover both ordered documents (ssso:ReservedService) and acquired documents
(ssso:ExecutedService). However I am not sure whether we want to express such
interals of document acquisition.

> To relate a holding and a status to the service a property (:status) is needed. 
> Maybe SSSO lacks of this property (ssso:status  "relates a service to a service event")???

A service in SSSO actually is an event.

> Exceptionally "in-house", "missing", "stolen" which Jakob said might be too fuzzy. 
> As far as I know these statuses are commonly added to a comment to the holding description.

If these comments contain information we should find out the core of it and
how to express it. If now, we should skip these comments as out of the scope
of a holding ontology. Keeping plain-text comments is no semantic modelling.

> ISO 20775 [1] maybe gives some more hints what other information we had to 
> think about:
> 
> availabilityStatus (the availability for loan or access of a copy or group of 
> copies in the context of a particular request)
> Possible statuses are:
> unknown
> available
> not available
> possibly available
>
> --> Maybe DAIA should handle the two other statuses too?

We reviewed ISO 20775 for design of DAIA and decided not to include fuzzy
ideas such as "unknown" and "possibly available" in lack of a clear use case.

> accessRestrictions (authentication or other requirements necessary 
> in order to access an electronic resource at a specific address)
> Possible statuses are
> unknown
> unrestricted access
> access with authorization
> preview only
> no online access
> restrictions unspecified
> access restricted URL based
>
> --> These seem to me like service limitation.

Yes. There are not URIs for specific limitation such as listed above
because nobody required it yet.

> Please tell us what you think about it...

As already said, I think we first need to find out what information
we need to know and then decide how to encode it. I can image
that its relevant to know whether a holding is

* currently in the collection of an Agent
* eventually not in the collection yet (ordered, in processing ...)
* eventually not in the collection anymore (stolen, missing, destroyed, withdrawn...)

But that's just a guess
Jakob


More information about the Dini-ag-kim-bestandsdaten mailing list