Associate volume number with isPartOf relation

[acka47]

Some resources have multiple volume ("2", "73", "...") information which aren't associated with the indicated isPartOf relations.

Examples:

• http://lobid.org/resource/HT002888677

EDIT: See #497 (comment) for the desired outcome.

[acka47]

Another example (from NWBib): http://lobid.org/nwbib/HT017903191

[acka47]

Currently it looks like this:

    "@id" : "http://lobid.org/resource/HT017903191",
     "isPartOf" : [ "http://lobid.org/resource/HT007384038", "http://lobid.org/resource/HT003613090" ],
     "volume" : [ "...", "52", "10" ],

You can not see that it is volume 10 of http://lobid.org/resource/HT007384038 ("Fundgrube Vergangenheit ") and volume 52 of http://lobid.org/resource/HT003613090 ("Beiträge zur Stadtgeschichte ").

In JSON-LD this should look something like this:

{
    "@id" : "http://lobid.org/resource/HT017903191",
     "numberingWithinMultiVolumeWork" : {
              "multiVolumeWork": "http://lobid.org/resource/HT007384038", 
              "volume": "10"
     },
     "numberingWithinSeries" : {
              "series": "http://lobid.org/resource/HT003613090", 
              "volume": "52"
     }
}

I am not sure whether properties etc. for this kind of approach already exist somewhere. Using RDA's "numbering within series" (http://rdaregistry.info/Elements/u/P60081) and "has numbering of part" (http://rdaregistry.info/Elements/u/P60080) might make sense but I am not sure usage is correct. Otherwise, we could also create RDF properties for this.

We will have to add this and retain the existing isPartOf triples as applications will break otherwise.

[acka47]

NWBib customers required that we would differentiate the isPart relation for

• volumes of a series (example: http://lobid.org/nwbib/HT015563767; morph, line 63),
• a volume of a multi-volume book (example: http://lobid.org/nwbib/HT017847410; morph, line 65) and
• articles in a journal, edited volume etc. (examples: http://lobid.org/nwbib/HT017306644, http://lobid.org/nwbib/HT018408723; morph, line 1233)

We should cover this requirement with this issue.

[acka47]

I made a separate issue (#702) for the specific isPartOf relation of articles as – not having numbering involved – it differs from the other two.

[acka47]

An example from hbz/lobid-vocabs#39 (comment) how the resulting JSON-LD should look like:

{
    "@id" : "http://lobid.org/resource/HT017903191",
     "volumeIn" : {
             "@type": "http://purl.org/lobid/lv#MultiVolumeWorkRelation",
              "multiVolumeWork": "http://lobid.org/resource/HT007384038", 
              "numbering": "10"
     },
     "inSeries" : {
             "@type": "http://purl.org/lobid/lv#SeriesRelation"
              "series": "http://lobid.org/resource/HT003613090", 
              "numbering": "52"
     }
}

[acka47]

Reopening. With the current implementation of this issue the former bibo:volume triples will be missing, thus this information will be missing in NWBib and Edoweb UI as well. No problem for NWBib but it may be one for Edoweb. Because of this we just switched this so that the changes are only on the staging system.

@literarymachine @jschnasse Please tell us when we can switch this to production. Can you live a few days without volume information or do you want to adjust Edoweb first before making this productive?

[fsteeg]

I think we should retain the old field and only add the new stuff we need to avoid breaking anyone.

[acka47]

My suggestion: We transform this again retaining the previous bibo:volume triples as soon as we also have #702 ready.

[dr0i]

Deployed to staging.

[acka47]

Looks good. +1 Noticed another issue we should solve after this, see #706 .

[dr0i]

Deployed to production, closing.