Use one property for relations to superordinated resources

[ChristophEwertowski]

As discussed today volumeIn.multiVolume contains similar information like inSeries (numbering, the id of the superordinated resource and a relation type). So they should be put together.
Example for volumeIn and inSeries:

"volumeIn" : [ {
    "multiVolumeWork" : [ {
      "id" : "http://lobid.org/resources/HT002888668#!",
      "label" : "lobid Ressource"
    } ],
    "numbering" : "2",
    "type" : [ "MultiVolumeWorkRelation" ]
  } ]

and

"inSeries" : [ {
    "numbering" : "73",
    "series" : [ {
      "id" : "http://lobid.org/resources/HT001236717#!",
      "label" : "lobid Ressource"
    } ],
    "type" : [ "SeriesRelation" ]
  } ],

should be something like:

"isPartOf" : [ {
    "numbering" : "2",
    "type" : "isPartOfRelation",
    "superordinated" : {
      "id" : "http://lobid.org/resources/HT002888668#!",
      "label" : "lobid Ressource"
    }
}, {
    "numbering" : "73",
    "type" : "isPartOfRelation",
    "superordinated" : {
      "id" : "http://lobid.org/resources/HT001236717#!",
      "label" : "lobid Ressource"
    }
} ]

If someone can think of a better term than isPartOf then we take that. Also there are cases where a journal volume is part of a periodical which at the moment can't be covered (example).
There are also resources which don't have an id for their superordinated resource, see example.

[fsteeg]

If we have that type field, we might want to use different types here to get the convenience of having that information without accessing the superordination, to display different labels, as we currently do, i.e. something like:

"isPartOf" : [ {
    "numbering" : "2",
    "type" : "inMultiVolumeWork",
    "superordinated" : {
      "id" : "http://lobid.org/resources/HT002888668#!",
      "label" : "lobid Ressource"
    }
}, {
    "numbering" : "73",
    "type" : "inSeries",
    "superordinated" : {
      "id" : "http://lobid.org/resources/HT001236717#!",
      "label" : "lobid Ressource"
    }
} ]

[acka47]

See also my comments (in German) in the KIM Wiki:https://wiki.dnb.de/pages/viewpage.action?pageId=125410060&focusedCommentId=125416192#comment-125416192 f

[acka47]

I am not sure whether we should keep the different typing. I found several cataloging errors where we would have better results when looking at the actual type of the superordinate resource.

[ChristophEwertowski]

I'm mostly with @acka47. If we found multiple errors just by browsing we shouldn't keep the current definitions of multiVolumeWorks and inSeries in our data. My proposal: Start with giving everything an isPartOfRelation-type and if we can access the publication type of the superordinate resource swap them with inSeries or inMultiVolumeWork. First correct data then enrichment.

[ChristophEwertowski]

Deployed to test.

• Example with (former) volumeIn, isPartOf and added zdb-label (production) / the same resource on test.
• Example with (former) inSeries (production) / the same on test.

If everything is correct, assign it to fsteeg because front-end changes are necessary.

[acka47]

This looks already really good. We need to do two minor adjustments before working on the UI adjustments. Basically, we will implement this as shown in the DINI KIM wiki

1. use lv:isPartOf instead of DC Terms
2. name the property lv:superordinate instead of lv:superordinated

[acka47]

@hagbeck these changes will be relevant for your mapping. Take a look at the German explanation at https://wiki.dnb.de/pages/viewpage.action?pageId=125410060&focusedCommentId=125416192#comment-125416192 to find out what will change.

[fsteeg]

Deployed to test: http://test.lobid.org/resources/BT000003404

[acka47]

Looks good. Found two problems, though.

1. Take 455 for numbering if none in 451 #459
2. Two equivalent isPartOf statements with both the superordinates hbz and ZDB ID lead to suboptimal HTML presentation. Example: http://test.lobid.org/resources/HT008355609

Nonetheless, I think we can deploy this for now and deal with the issue in the next step. +1

[acka47]

Ping @hagbeck. The changes are now on production and you probably have to re-configure your transformation. A good example is http://lobid.org/resources/HT002888677?format=json where inSeries and volumeIn don't exist anymore and are both subsumed under isPartOf.