Using RDA datatype and object properties in Sinopia RTs (and Sinopia data)

[briesenberg07]

Using RDA datatype and object properties in Sinopia resource templates

📢 DECISION 2022-12-01:
Use canonical properties in Sinopia RDA resource templates. If a need for datatype/object properties in RDA/RDF data arises, perform post-processing on description sets to substitute datatype/object props where applicable 📢

---

I believe that we will want to create RDA/LRM/RDF data using RDA datatype and object properties wherever possible. One argument for doing this:

• uwlib-cams MARC2RDA project is mapping MARC data points to either object or datatype properties, not canonical properties
• Sinopia RDA/LRM/RDF templates may be more useful if they align well with RDA/LRM/RDF data converted from MARC

UW work on new Sinopia RDA/LRM/RDF templates began with the assumption that 'canonical' RDA properties would be used, as was the case with legacy (2019/2020) RDA Sinopia templates. So, changes need to be made to make use of the object and datatype properties.

RELATED

• Not getting labels for drop-down datatype/object property options (sinopia_maps #67)
• [?] Bring in RDA datatype and object prop prop_sets (map_storage #23)
• 2022 sinopia_maps meetings discussion:
  • 2022-08-15, see Object and datatype properties
  • 2022-09-01, see 005_replace_canonical_props.py

[CECSpecialistI]

We have decided for the MARC2RDA transform that we'll use object and datatype properties, and recommend that others do the same. we're recording canonical properties in the spreadsheets right now because it will be easy to change them based on values of the "recording method" column later. So, in short, data converted from MARC to RDA-RDF will make use of datatype and object properties.

The constraints on data entry you mention will be (I think) a good thing. Adding a literal value for a lookup was always an unsatisfactory work-around in my opinion, and we should really be using IRI's and entering literals as rdfs:labels when we have lookups. In a transform, though, we'll need to transform legacy data...can we switch from object to datatype properties in the transform based on value types?

[briesenberg07]

Thanks for your thoughts @CECSpecialistI !

I think your closing question...

In a transform, though, we'll need to transform legacy data...can we switch from object to datatype properties in the transform based on value types?

...is about the MARC2RDA transform work, so I'm going to leave that for @gerontakos or @pan-zhuo , and/or for a discussion or issue in the MARC2RDA repo.

[gerontakos]

Yes, we can switch from object to datatype properties very easily. Our data will not only be processed locally, it will be in a pipeline here we can do just one thing at a time. So we could do everything in the mapping, then output, then process the data to check object/datatype properties' correspondence to their values, changing it as needed. The local processing contrasts to the Sinopia resource template work because the data produced from those templates is not local but in Sinopia; we'd have to export the data, process it locally, then (we expect) post the data using the API and, in the process, overwrite the old data. Obviously much can go wrong.

[briesenberg07]

Option one: Create datatype- and object-property prop_sets

There are at least two possible strategies for doing this, but I'm recommending creating new prop_set instances for datatype and object properties, and recording implementation_set data in these when designing templates.

Advantages

• IRIs for canonical RDA properties can be constructed from those for datatype or object property IRIs, and vice-versa. BUT not all canonical RDA properties have object-property versions. So it would be 'safer' to work from an object-property prop_set and convert IRIs to canonical versions as needed, than it would to go the other way.
• Because all property IRIs for a given element (datatype, object, and canonical) share the same P-number, use of datatype and object prop_sets shouldn't hinder retrieval of Toolkit URLs for output as "remark URLs" in the Sinopia templates.

Disadvantages

• Existing property implementations will need to be moved to datatype- and/or object-property prop_sets from canonical prop_sets
• Template designers will need to move between a greater number of prop_set instance files when authoring templates
• The use of datatype/object property IRIs in Sinopia templates puts additional constraints on data entry. In 2019/2020 Sinopia cataloging, when QA lookups would fail, catalogers would often enter literal values for a given property template. In property templates using RDA object properties, for example, entry of a literal value would not be acceptable (bad data).

[briesenberg07]

Option two: Process Sinopia RTs to substitute canonical properties for object/datatype based on PT configuration

This is what is being done as of 2022-11-30. This is creating an issue which will be difficult to solve without significantly altering the existing workflow.

[briesenberg07]

Option three: Use canonical properties in Sinopia RDA resource templates. If a need for datatype/object properties in RDA/RDF data arises, perform post-processing on description sets to substitute datatype/object props where applicable

...

[CECSpecialistI]

This honestly seems the most practical to me? The only potential issue I see is with accepting triples for legacy data converted from MARC and added to sinopia through api, but we will probably need separate templates to hold that data anyway due to inconsistencies between how we can convert data from MARC and how we would ideally create RDA data natively from map's

[briesenberg07]

Thanks for weighing in @CECSpecialistI ! As it turns out this is the direction I believe we'll be going in (at least for the time being). More details soon.

[briesenberg07]

See Made the 'easy fix' proposed in sinopia_maps #67 .