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

Klee, Carsten Carsten.Klee at sbb.spk-berlin.de
Tue May 21 15:08:50 CEST 2013


Hi Philipp, Jakob et al.,

thanks for your input. 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.
 
Maybe I think too complicated. But how do you want to model those statuses other than via services?

Here is what I'm imagining:

# An item is ordered
:Holding dso:hasService [
	a 		dso:BuyExchangePresent ;
	:status	ssso:ExecutedService .
]

# An item is in acquesition
:Holding dso:hasService [
	a 		dso:Acquesition ;
	:status	ssso:ExecutedService .
]

As you can see, I added missing classes "dso:BuyExchangePresent" and "dso:Acquesition" assuming that they are services too.

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")???

What DAIA provides is the availability for a service:

# An item is ready/available for Loan
:Holding daia:avialableFor dso:Loan .

# An item missing/unavailabale
:Holding daia:unavialableFor dso:Loan .

Given that a holding ontology does not have to care about the statuses Philipp listed. But can make reuse of the existing vocabs. 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.

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?

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.

Please tell us what you think about it...

Cheers,

Carsten

[1] <http://www.loc.gov/standards/iso20775/ISOholdings_V1.0.xsd#>

_______________________________________________
Carsten Klee
Abt. Überregionale Bibliographische Dienste IIE
Staatsbibliothek zu Berlin - Preußischer Kulturbesitz

Fon:  +49 30 266-43 44 02


> -----Ursprüngliche Nachricht-----
> Von: dini-ag-kim-bestandsdaten-bounces at lists.d-nb.de [mailto:dini-ag-kim-
> bestandsdaten-bounces at lists.d-nb.de] Im Auftrag von Jakob Voß
> Gesendet: Dienstag, 21. Mai 2013 14:19
> An: dini-ag-kim-bestandsdaten at lists.d-nb.de
> Betreff: Re: [Dini-ag-kim-bestandsdaten] Definition and scope of Holding
> 
> Hi,
> 
> Philipp wrote:
> 
> > I like your picture, also I am not sure if your connections to Service
> > are the only possibilities here. However, I think we should concentrate
> > for the moment at the information not related to services. How about
> > postpone these questions, because we need here certainly the opinion of
> > Jakob Voß.
> 
> I also like Carsten's picture and description and I agree to concentrate
> on information not related to services - this can better be expressed
> with a remaining part of DAIA ontology and Document Service Ontology. So
> better remove the "service portfolio".
> 
> > What we could also add as general information is the status of item in
> > the library: ordered, in-house, in-acquisition, ready, missing, ...
> 
> Yes but we should take care not to introduce to much implicit
> assumptions about these status - they may be handled very differently
> among institutions. Without a clear definition and explanation terms
> such as "ready" or "in-house" are rather fuzzy.
> 
> We should also clarify whether such status imply anything on services
> and on the relation between Item and Agent. For instance is a missing
> Item still held by its Agent (I'd say so)? How do we find out the most
> used and most relevant of these status?
> 
> By the way status might also be encoded as sub-property of holds/heldBy:
> for instance a document that has been ordered is held by an Agent in a
> special way. But first let's find out which status are relevant at all.
> 
> Carsten wrote:
> 
> > If we discard the "service portfolio" then the remaining scope of
> > Holdings description would be:
> >
> > 1. general holdings information
> > 2. current status
> 
> as long as this is not confused with availability
> 
> > (3. hooks)?
> 
> better give this another name, such as "relations to agents and
> documents".
> 
> Jakob
> 
> --
> Jakob Voß <jakob.voss at 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
> _______________________________________________
> Dini-ag-kim-bestandsdaten mailing list
> Dini-ag-kim-bestandsdaten at lists.d-nb.de
> http://lists.d-nb.de/mailman/listinfo/dini-ag-kim-bestandsdaten


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