Relation between Item and Location

[cKlee]

How should a relation between an item and a location be defined?

@prefix gn: <http://www.geonames.org/ontology#> .

holding:Item gn:locatedIn gn:Feature .

or

holding:Item dcterms:spatial dcterms:Location .

other ideas?

[nichtich]

The current (soon outdated) DAIA Ontology includes the class daia:Storage, but this is not fixed yet. Here, an instance of daia:Storage is "place where items are stored" or "a physical location of the item (stacks, floor etc.)". There is an open issue about the purpose of daia:Storage and how to express current location vs. general location vs. location where an item is made available.

Let me elaborate with an example of an Item (a copy of a document) that is held by an Agent (a library):

$item a holding:Item ;
    holding:heldBy $agent .

To obtain the general location (where an item belongs, no matter whether it is actually there at the moment) one could look up the location (address, coordinates..) of $agent. In the case the helding item and the location coincide. If the item is located at a more specific place (e.g. at a specific building), this pattern does not work anymore, so another property may be needed and useful to specify the general location.

To express the current location, one could just use dcterms:spatial.

$item dcterms:spatial $location .

One could also decide not to distinguish "current" and "general" location. E.g. the location of a copy of a book on loan is the library, although the copy is actually at the patron's home.

I am not sure whether this could also be used for digital items. What's the location of a digital copy?

To express the location where an item is made available, one must specify what is meant by "made available". For instance an item can be made available for loan. In this case the location is a property of the loan service event:

$item daia:availableFor $service .
$service a dso:Loan ;
    dcterms:spatial $location .

[acka47]

Just a short note: You shouldn't use dct:spatial in this context as dct:spatial relates a resource to a spatial thing the resource is about ("Spatial Coverage").
dct:spatial is subproperty of dct:coverage, which is commented in the vocabulary as follows:

The spatial or temporal topic of the resource, the spatial applicability of the resource, or the jurisdiction under which the resource is relevant.

Thus, dct:spatial belongs to the realm of subject indexing and doesn't fit in this context.

[cKlee]

Hmm? What about using CIDOC CRM?
see http://www.cidoc-crm.org/rdfs/cidoc_crm_v5.1-draft-2013May.rdfs
and http://www.cidoc-crm.org/html/5.0.4/cidoc-crm.html#P53

@prefix crm: <http://www.cidoc-crm.org/cidoc-crm/>

#implies item is a physcal object
$item crm:P53_has_former_or_current_location [
    a crm:E53_Place ;
    dct:title "Sonderstandort" .
]

Besides I think there is still the problem to give the item a label for its location(s).

[cKlee]

My crm suggestion does not allow services to be related to crm:E53_Place, but only physical objects. Too bad I searched a lot but didn't found another good ontology that could fit in.
What do we need? Something that relates a thing to a spatial feature, right? A spatial feature of a resource then might have a label and a place.
If this can't be found anywhere else I would suggest to define our own?

[cKlee]

Maybe this could look like

holding:SpatialFeature a owl:Class ;
    rdfs:label "spatial feature" ;
    rdfs:comment "A spatial feature describes the spatial characteristics of the resource."@en ;
    rdfs:isDefinedBy <> .

holding:spatialFeature a owl:ObjectProperty ;
    rdfs:label "has spatial feature"@en ;
    rdfs:comment "Relates a thing to a spatial feature."@en ;       
    rdfs:range holding:SpatialFeature ;
    rdfs:isDefinedBy <> .

holding:locality a owl:ObjectProperty ;
    rdfs:label "locality"@en ;
    rdfs:comment "Denotes a location as a spatial feature of the resource."@en ;       
    rdfs:domain holding:SpatialFeature ;
    rdfs:range dct:Location ;
    rdfs:isDefinedBy <> .

holding:tag a owl:ObjectProperty ;
    rdfs:label "tag"@en ;
    rdfs:comment "Denotes a naming as a spatial feature of the resource."@en ;   
    rdfs:domain holding:SpatialFeature ;
    rdfs:isDefinedBy <> .

$item holding:spatialFeature [
    a holding:SpatialFeature ;
    holding:locality [
        a dct:Location ;
        dct:title "Handbibliothek Z" ;
        ex:building <http://example.org/mylibrarybuilding>
    ] ;
    holding:tag "HB Z 123"
] .

[cKlee]

Why I don't receive mails from this issue?

[nichtich]

I strongly doubt that we need to define new classes and properties for locations and if so, these should better be placed in another ontology instead of polluting the holding ontology. We should first agree on what is actually meant by "the location of an item". If the location should be any "spatial region or named place", then dct:Location is fine. If we want restriction to physical places, maybe schema:Place or geo:SpatialThing are better choices.

[cKlee]

All right! Now I got an email from this issue.
@nichtich As I tried to explain, "location of an item" is not enough if we want to give the item a label or else in the context of a location. Therefor I suggested the class SpatialFeature which can list the spatial characteristics of the item.
I haven't found an ontology for that. The classes you mentioned are about geographical regions, places, adresses etc. and not properties of a thing in the context of a location.

[nichtich]

@cKlee What's the "label of an item in the context of a location" or a "naming as a spatial feature"?! Can you give some real world examples, please? Both items and locations can have multiple labels (simple triples), but combining item, name, and location smells like an n-ary relationship.

[acka47]

Perhaps @hagbeck has some thoughts about utilizing CIDOC CRM for holdings data as he has extensive knowledge on CIDOC CRM...

[cKlee]

@nichtich What about n-ary relationships?

An item may have multiple locations, right? For instance the last volume of a journal is available in the reading room shelf and the rest is on stack. The part in the reading room gets an extra label or tag or sticker or else with a local callnumber. That is in my opinion a "label of an item in the context of a location". When I look in our reading room I can give you a real world example. But I'm too lazy now.

There are certainly other local features which all come together if an item is in the context of a location. E.g. it can have an extra comment ("Benutzung nur im Lesesaal"), or a moving wall (like I mentioned the last volume).

In the latter case there is the need for an other ontology (moving wall ontology).

I'm open for everything what can help to express such things. Maybe I'm thinking to complicated again. But I think there is the need for n-ary relationships in this case.

[acka47]

If an n-ary relationships is needed one might consider using the open annotation model. Bibframe uses a similar approach for holding information so this might work. If you provide a concrete example, I will try to model it tomorrow using the OA model.

[cKlee]

@acka47 ZDB Pica example:

Title:
2110 2668162-6
4000 IHS Jane's space systems & industry

Item:
4800 !009000046!101005-0 <1a> Berlin, Staatsbibliothek zu Berlin - Preußischer Kulturbesitz, Haus Potsdamer Straße
7100 Zsn 70488 @ u % l
7109 !!Lesesaal!! ; HB 17 Rg 500 ((letzter Jg.))
7120 /b2012/13-
7800 242635490

4800 is the institution/building. 7800 is the item id. 7100 the global callnumber. 7109 !!...!! is the site/place (its a literal). ((...)) is a comment to the local callnumber HB... .

[nichtich]

@cKlee: if an item has multiple locations that it's either a digital item with multiple, identical copies, or it is a physical items that contains of multiple items, each with a different location. As long as these item parts are cluttered in one RDF resource, it makes no sense to further distinguish locations. Given your ZDB example I see two possible ways to model in RDF:

# one item with multiple call numbers
<http://example.org/item/242635490>
    ex:label "Zsn 70488" , "HB 17 Rg 500" .

# multiple items, each with a call number
<http://example.org/item/242635490>
  dcterms:hasPart [
    ex:label "Zsn 70488" 
  ] , [ 
    ex:label "HB 17 Rg 500" 
  ] .

Both variants have their own disadvantages, but these disadvantages rather origin from the Pica data than the way it is mapped to RDF.

[cKlee]

@nichtich What does the Pica data has to do with this? The item is a copy of a document. If the document is series with multiple parts, then the item has multiple parts too. Thus you have to describe the parts through a single item, like you did it in the second example.
Besides the second example might be a good solution. What is the disadvantage?

# multiple items, each with a call number
<http://example.org/item/242635490>
  dcterms:hasPart [
    ex:label "Zsn 70488" ;
  ] , [ 
    ex:label "HB 17 Rg 500" ;
    ex:place [
        a dct:Location ;
        dct:title "Lesesaal"
    ] ;
    ex:comment "letzter Jg."
  ] .

[nichtich]

@cKlee At least one disadvantage is the lack of identifiers for parts of items, so one has to deal with blank nodes. By the way one could also combine both variants:

<http://example.org/item/242635490>
  ex:label "Zsn 70488", "Zsn 70488" ;
  dcterms:hasPart [
    ex:label "Zsn 70488" 
  ] , [ 
    ex:label "HB 17 Rg 500" 
  ] .

[cKlee]

@nichtich Just a quick comment on blank nodes: With this kind of material we trying to describe, there is no way around blank nodes. Avoiding blank nodes where you can is a good thing (even if you don't know why). But if it is necessary at another point, in the end the data haverster has to deal with blank nodes anyway.

In this case I see the disadvantege of a missing identifier: If a part (a b-node) is connected to a place, it might be very difficult to ask: Which items are located at Place X? Because what you get as the answer is the b-node.

But with the dso services it is the same:

$item daia:availableFor [
    a dso:Loan ;
    dcterms:spatial $location 
] .

Which items are available for a dso:Loan at Place X? Answer: a b-node.

So if we stick with this, there is still the open question what relates an item/part an a location?

[hagbeck]

In the past years I have dealt with CIDOC CRM within the context of archaeological and bibliographical metadata and their linking. As a result the necessity to describe the relation between 'items' respectively 'physical object' and their 'location' transpired.
I used FRBRoo for the description of bibliographical metadata, by which a "natural" linking to 'locations" is given:

efrbroo:F5_Item 
  subClassOf ecrm:E84_Information_Carrier 
  subClassOf ecrm:E22_Man-Made Object 
  subClassOf ecrm:E19_Physical_Object 
  subClassOf ecrm:E18_Physical_Thing  .
ecrm:E18_Physical_Thing 
  ecrm:P53_has_former_or_current_location ecrm:E53_Place .
ecrm:E19_Physical_Object 
  ecrm:P55_has_current_location ecrm:E53_Place .
ecrm:E53_Place 
  ecrm:P87_is_identified_by ecrm:E44_Place_Appellation .
ecrm:E53_Place 
  ecrm:P89_falls_within ecrm:E53_Place .

e.g.(last volume):

@prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# . # RDF Site Summary (RSS) 1.0
@prefix rdfs: http://www.w3.org/2000/01/rdf-schema# . # RDF Schema vocabulary (RDFS)
@prefix ecrm: http://erlangen-crm.org/120111/ .
@prefix efrbroo: http://erlangen-crm.org/efrbroo/120219/ .
@prefix f5: http://example.org/frbroo/F5/ .
@prefix e53: http://example.org/crm/E53/ .
@prefix e44: http://example.org/crm/E44/ .
f5:242635490 a efrbroo:F5_Item ;
  ecrm:P55_has_current_location e53:Lesesaal ;
  rdfs:label "HB 17 Rg 500" . 
e53:Lesesaal a ecrm:E53_Place ;
  ecrm:P87_is_identified_by e44:Lesesaal ;
  ecrm:P89_falls_within e53:HausPotsdamerStraße .
e44:Lesesaal a ecrm:E44_Place_Appellation ;
  rdfs:label "Lesesaal" .
e53:HausPotsdamerStraße a ecrm:E53_Place ;
  ecrm:P87_is_identified_by e44:HausPotsdamerStraße ;
  ecrm:P89_falls_within e53:StaBi .
e44:HausPotsdamerStraße a ecrm:E44_Place_Appellation ;
  rdfs:label "Haus Potsdamer Straße" .
e53:StaBi a ecrm:E53_Place ;
  ecrm:P87_is_identified_by e44:StaBi .
e44:StaBi a ecrm:E44_Place_Appellation ;
  rdfs:label "Staatsbibliothek zu Berlin - Preußischer Kulturbesitz" .

I would make a connection between "Zsn 70488" and "HB 17 Rg 500" in the following way:

@prefix e78: http://example.org/crm/E78/ .
f5:242635490 a efrbroo:F5_Item ;
  ecrm:P46_forms_part_of e78:Zsn70488 ;
  rdfs:label "HB 17 Rg 500" . 
e78:Zsn70488 a ecrm:E78_Collection ;
  rdfs:label "Zsn 70488" .

According to FRBR a current 'serial work' has not a manifestation of its own and consequently no item. Therefore '7100' (in this case "Zsn 70488") is not the 'identifier' of an item, but rather of a sort of collection.

[cKlee]

@acka47 @nichtich
Thanks @hagbeck !

I have some problems with the identifiers you use (e53:Lesesaal, e53:HausPotsdamerStraße, e44:StaBi) because they are quite arbitrary. I guess we could run into trouble if we are suggesting to define them on the fly. Has anybody experience with this?

But without these identifiers it could look like this:

$242635490 a holding:Item ;
    dct:hasPart [
        rdfs:label "HB 17 Rg 500" ;
        ecrm:P55_has_current_location [
            a ecrm:E53_Place ;
            ecrm:P87_is_identified_by [
                a ecrm:E44_Place_Appellation ;
                rdfs:label "Lesesaal"
            ]  ;
            ecrm:P89_falls_within [
                a ecrm:E53_Place ;
                ecrm:P87_is_identified_by [
                    a ecrm:E44_Place_Appellation ;
                    rdfs:label "Haus Potsdamer Straße"
                ] 
            ]
        ] 
    ] ;
    rdfs:label "Zsn 70488" .

What I'm missing in CIDOC-CRM is a relation between a place and a organisation/group/legal body. This way a place could have an ownership li

$place ex:owner <http://ld.zdb-services.de/resource/organisations/DE-1a> .

[acka47]

@cKlee I don't think that "ownership" of a place is the right terminology, e.g. the rooms an institution is located in often are rented. I better like the approach of the organization ontology (http://www.w3.org/ns/org) relating an organization to a site. You could use org:site for for the relation between a place and an organisation:

<http://ld.zdb-services.de/resource/organisations/DE-1a> http://www.w3.org/ns/org#site  $place.

We didn't use the org ontology in lobid.org though, as you have many blank nodes if you want to relate an organization to its site adress. (One problem is that org ontology proposes using the vcard:Vcard class instead of relating a site directly to the adress data via vcard:adr. See e.g. https://wiki1.hbz-nrw.de/display/SEM/Organization+Ontology)

[cKlee]

@acka47 @nichtich @hagbeck @dini-ag-kim/bestandsdaten

I was thinking if the relation between an item and a location is always connect with a service? But it would be more complicated to pull this information from the data. E.g. the item at location X is available for presentation but not for loan.

The advantage is to get rid of the dct:hasPart.

@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> .
@prefix org: <http://www.w3.org/ns/org#> .
@prefix daia: <http://uri.gbv.de/ontology/daia/> .
@prefix dso: <http://purl.org/ontology/dso#> .

$242635490 a holding:Item ;
    daia:availableFor [
        a dso:Presentation ;
        event:place [
            org:siteOf <http://ld.zdb-services.de/resource/organisations/DE-1a> ;
            rdfs:label "Leesesaal"
        ]
    ] ;
    rdfs:label "Zsn 70488" .

But this time the local label "HB 17 Rg 500" got lost :-(

Here we are again with dct:hasPart

$242635490 a holding:Item ;
    dct:hastPart [
        rdfs:label "HB 17 Rg 500" ;
        daia:availableFor [
            a dso:Presentation ;
            event:place [
                org:siteOf <http://ld.zdb-services.de/resource/organisations/DE-1a> ;
                rdfs:label "Leesesaal"
            ]
        ] ;
    rdfs:label "Zsn 70488"
    ]

[acka47]

@acka47 @nichtich

Just for the sake of completeness. As I announced, I had a look into the Open Annotation Model regarding representation of holdings. Actually, I don't see the benefit of using an annotation to express a holding. And if you would like to use OA you'd have to define a lot new properties, I believe.

That's what I arrived at:

<http://ld.zdb-services.de/resource/2668162-6>
    a bibo:Periodical ;
    dc:title "IHS Jane's space systems & industry" .

<http://staatsbibliothek-berlin.de/annotation/01>
    a oa:Annotation ;
    oa:annotatedBy <http://ld.zdb-services.de/resource/organisations/DE-1a> ;
    oa:hasTarget <http://ld.zdb-services.de/resource/2668162-6> ;
    oa:hasBody _:Body ;
    oa:motivatedBy ex:Holding .

_:Body
    a ex:Holding ;
    ex:holdingInstitution  <http://ld.zdb-services.de/resource/organisations/DE-1a> ;
    ex:item <http://staatsbibliothek-berlin.de/item/242635490> .

<http://staatsbibliothek-berlin.de/item/242635490>
   dct:hasPart [
    rdfs:label "Zsn 70488"
        ] , 
        [
        rdfs:label "HB 17 Rg 500" ;
        daia:availableFor [
            a dso:Presentation 
            ]  ;
            event:place [
                org:siteOf <http://ld.zdb-services.de/resource/organisations/DE-1a> ;
                rdfs:label "Leesesaal"
            ]
        ] ;
    ] .

As you can see, the problems that are going to be solved here, won't be solved with OA but there is just a level of indirection added. I really would like to know how they are going to express holdings as annotations in Bibframe...

The benefit of using the OA approach is, though, that you easily could document provenance information (Who did when add which holding information?). The drawbacks are that you would basically move the representation problem to another level...

[cKlee]

@acka47 @nichtich @dini-ag-kim/bestandsdaten @cKlee
All right! Here is MAYBE another possibility based on my previous comment.

Take in account that an item at a location is always connected with an service.

$242635490 a holding:Item ;
    rdfs:label "Zsn 70488" ;
        daia:availableFor [
            a dso:Presentation ;
            event:place [
                org:siteOf <http://ld.zdb-services.de/resource/organisations/DE-1a> ;
                rdfs:label "Leesesaal"
            ]
        ]
    ]

A dso:Presentation is a ssso:ServiceEvent which can be limited through a ssso:ServiceLimitation.

What I think we can do is limit the service to a part of an item. The part of the item is only identified through a literal value "HB 17 Rg 500".

Now give the part of the item, identified through its literal value, to the service limitation as it's value.

$serviceLimitation rdf:value "HB 17 Rg 500" .

When I'm not totally wrong here, then

$presentation ssso:limitedBy [
    rdf:value "HB 17 Rg 500"
]

is the same as

$presentation ssso:limitedBy "HB 17 Rg 500".

This gives us the whole description

$242635490 a holding:Item ;
    rdfs:label "Zsn 70488" ;
        daia:availableFor [
            a dso:Presentation ;
            event:place [
                org:siteOf <http://ld.zdb-services.de/resource/organisations/DE-1a> ;
                rdfs:label "Leesesaal"
            ] ;
            ssso:limitedBy "HB 17 Rg 500"
        ] 
    ]

Does this make sense?

[nichtich]

@cKlee How do you assume that the following graphs equal? Did I miss some basic inference rule?

$presentation ssso:limitedBy [ rdf:value "HB 17 Rg 500" ] .
$presentation ssso:limitedBy "HB 17 Rg 500" .

I'd prefer not to use rdf:value if possible.

[cKlee]

@nichtich @dini-ag-kim/bestandsdaten @hagbeck @acka47 @dr0i @cKlee
Well, sure it's possible! While this is not the scope of the holding-ontology, I don't want to stress this here. It's just what I've read http://milicicvuk.com/blog/2011/08/18/extended-curie-prefixlocalnamekey/

It convinced me that both are nodes, and both nodes have no name but only a vaue. I can't see any differernce. But as I said, don't let us stress this here.

If nobody objects we will go with event:place and org:site. But this includes an agreement that an item is always connected with an location through a service.

[nichtich]

In SSSO I added a section on service locations. I suppose the most popular properties are event:place (used to relate services to places as geo:SpatialThing) and schema:location (used to relate both organizations and services to places as schema:Place or schema:PostalAddress).

For document services ( location where an item is made available ), one can use both, event:place and schema:location, depending on the kind of place (geo:SpatialThing, schema:Place and/or schema:PostalAddress).

To specify the location of a holding item, independent of document services ( current location ), we may need to craft a new holding:location property. For instance an item may be located in the closed stacks but made available in the reading room.

To specify the location of the holding institution ( general location ), one could use org:site (with range òrg:Site or schema:location). This would cover all three different kinds of locations, mentioned in my earlier comment.