Remove obsolete properties

[dr0i]

We have a workaround lv:nameOfContributingCorporateBody (introduced with hbz/lobid#38), where we subsume literals of corporate bodies, be they creators or contributors. I think this property will be made obsolet by the new lv:contributorOrder , right?

[acka47]

I re-neamed this ticket to a more general task: remove obsolete properties after properly implementing API 2.0.

When we are properly done with API 2.0 the following properties should be obsolete and should be removed before going into production:

• contributingCorporateBodyLabel: with Differ between contributing persons and corporate bodies #40 corporate body search will work with `?q=corporateBody
• contributorLabel: person search will work with ?q=contributor, see also Differ between contributing persons and corporate bodies #40
• subjectlabel, as a subject search works with ?q=subject.*:Pferd
• subjectChain, provided that there is a way to search for a subject chain by using the subject list
• contributorName, see Add persons and corporate bodies without GND ID to "contributor"/"creator" array lobid-rdf-to-json#17

[acka47]

The question is whether these properties are really obsolete or whether they still contain information that isn't found elsewhere. For example, I just noticed that subjectlabel contains information from fields 710/711 that is not – and should not – be moved to the subject array. Example TT002234459 (snippet):

<datafield tag="710" ind1="-" ind2="1">
  <subfield code="a">
Wandern, Diez, Lahnstein, Rhein-Lahn-Info, Rhein, Lahn, Wirtschaftsförderung
  </subfield>
</datafield>

We might not want to have it in the subject array as it would be mistaken as some part of an RSWK subject chain. (There is still the possibility, though, that we need a field like subjectChain or subjectOrder for providing required functionality like "Themensuche" in NWBib).

We will have to take this into account before removing properties. One possibility for 710/711 might be to switch back to dc:subject for this when we don't list the strings together with alternate names of GND subjects...

[acka47]

Talking to @jschnasse the other day, it became clear that we should keep "subjectOrder" as we can not group multiple subject chains in a subject array.

[dr0i]

Look at the status quo of API 2.0 I think we may close this ticket. Only subjectChain is still used and will be in the future because at the moment json-ld doesn't support lists in lists, yes @acka47 ?

[acka47]

In #8 (comment), I ticked the properties that already have been removed. Is this correct? This means, we will keep subjectLabel, subjectOrder and subjectChain for now. I would be ok with this.

[acka47]

I found another property that should be removed: volume. Since lobid/lodmill#497 we don't need it anymore and only retained it because edoweb still needed it, see lobid/lodmill#497 (comment) ff.

[acka47]

Reopening. These still have to be removed from the context/labels.json:

• contributingCorporateBodyLabel (http://purl.org/lobid/lv#nameOfContributingCorporateBody)
• contributorLabel
• creatorName
• eissn
• hasFormat
• hasPart
• inDataset
• issued
• lccn
• placeOfPublication
• prefLabel
• primaryTopic
• publicationStatement
• publisher
• subjectName
• volume
• wikipedia