[Dini-ag-kim-bestandsdaten] AW: Status of Holding [was Definition and scope of Holding]

[Klee, Carsten]

Hi everyone!

Jakob wrote:
 
> 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.

All right, but then we need more input from the experts who know their data. Because we cannot extract status information from uncoded data by just reviewing (cataloguing) formats like ISO 20775 [1], GBVKat [2], ZETA [3] etc. if the status information is hidden in comments.

I know that our library uses the expression "Kriegsverlust möglich" (possibly lost in war). This is one of the most fuzziest status I can imagine.

So my question is: Do we want to collect such statuses (maybe only the most common ones) and try to express them? Or is it better to leave this information in the comments to the holding where it comes from?

> 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.

Maybe for patron driven acquisition? 
 
> 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.

Well, this status is worth to communicate to the patron, I think. Especially when the order was patron driven it might be a valuable status information for her.


> > 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.

Then I must admit, that I don't fully understand SSSO. There are status classes, but how can they be connected with the document?


> > 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.

See "Kriegsverlust möglich".

> > 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.

I think we should keep the in mind. I added them to the proposed status list [4].

> > 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...)

Also added to the proposed status list [4].

Cheers!

Carsten

[1] <http://www.loc.gov/standards/iso20775/>´
[2] <http://www.gbv.de/bibliotheken/verbundbibliotheken/02Verbund/01Erschliessung/02Richtlinien/01KatRicht/inhalt.shtml#Level2>
[3] <http://www.zeitschriftendatenbank.de/erschliessung/arbeitsunterlagen/zeta/#c10773>
[4] <https://wiki.dnb.de/display/DINIAGKIM/Scope+of+Holdings>