RDA data provenance templates

[briesenberg07]

Resources

• RDA Toolkit > Guidance > Data provenance
• RDA Toolkit > Guidance > Resource description > Minimum description of a resource entity
• RDA Toolkit > Guidance > Resource description > Coherent description of an information resource
• MARC2RDA > Discuss Data Provenance and Administrative Information in Library Linked Data: Reviewing RDA in RDF, BIBFRAME, and Wikidata (#391)
• Data Provenance and Administrative Information in Library Linked Data: Reviewing RDA in RDF, BIBFRAME, and Wikidata - Shoichi Taniguchi - doi.org/10.1080/01639374.2023.2178048

2019/2020 WAU BF AdminMetadata resource template

https://api.sinopia.io/resource/WAU:RT:BF2:AdminMetadata
WAU_RT_BF2_AdminMetadata.ttl.txt

Template details

• WAU_RT_BF2_AdminMetadata
  • bflc:catalogerId: literal pt, repeatable
  • bf:status: nested-resource pt, repeatable
    • WAU_RT_BF2_Status (https://api.sinopia.io/resource/WAU:RT:BF2:Status)
      • bf:code: literal pt, repeatable
  • bflc:encodingLevel: lookup pt - id.loc.gov/vocabulary/menclvl, repeatable
  • bf:descriptionConventions: lookup pt - id.loc.gov/vocabulary/descriptionConventions, repeatable
  • bf:source: lookup pt - LOC organization [names (rwo)], repeatable
  • bf:descriptonLanguage: lookup pt - id.loc.gov/vocabulary/languages, required
  • bf:creationDate: literal pt, repeatable
  • bf:changeDate: literal pt, repeatable
  • bf:descriptionAuthentication: lookup pt - id.loc.gov/vocabulary/marcauthen, repeatable
  • bf:generationProcess: nested-resource pt, repeatable
    • WAU_RT_BF2_GenerationProcesss (https://api.sinopia.io/resource/WAU:RT:BF2:GenerationProcess)
      • rdfslabel: literal pt, repeatable

[briesenberg07]

Should this template be nested or standalone?

• Nested = bnode for admin metadata / standalone = IRI for the metadata Work
• Nested is (much) more convenient for catalogers

Nested seems like the best choice for reasons of ease of use of the templates. But is there any reason (for example, a best practice for use of the RDA/RDF ontology) why bnodes shouldn't be created that I'm not aware of?

[briesenberg07]

Thank you @pan-zhuo -- I stand corrected! Now looking at the Toolkit's Minimum description of a resource entity, and will add this to references at top of discussion.

[briesenberg07]

Attempting to synthesize Toolkit documentation which bears on this question

...that is, must the administrative metadata template(s) be standalone or can it/they be nested??

Proposed requirements for metadata template(s) based on Toolkit documentation

Pulling requirements from multiple Toolkit documents, see "References" above

• Minimum description of a Work must include one of the following elements: appellation of work or title of work or [...] identifier for work
  • @pan-zhuo states above that metadata Work templates should be standalone (meaning that metadata Works would not be blank nodes but would have Sinopia IRIs)
  • I don't interpret the guidance for minimum description of a work (which doesn't speak directly to linked-data implementation scenarios) to state that they must have IRIs as opposed to blank nodes (Zhuo also referenced a discussion in the MARC2RDA repository which I may not fully understand, however, perhaps the reason why a metadata Work must have an IRI is there?)
  • If identifier for work is just one option, why couldn't we create a blank node for the metadata Work and provide a title? (Admittedly, I can't imagine how a title for the metadata work would be of much use, or would capture any information not captured elsewhere in the metadata W/E such as cataloger ID, date, etc.)
• Minimum description of a Work must also include one of the following elements: Work: expression of work with a value of Expression: appellation of expression or Expression: title of expression or [...].
  • In general, I find Toolkit guidance difficult to understand when attempting to determine how RDF triples might need to be constructed to be conformant with the ontology; same applies here. BUT I read this to mean that you can't describe a work without an expression.
  • If we need a metadata Work and Expression, I still believe that this can be accomplished with blank nodes. This would be a nested resource template which includes another nested resource template. This structure was used for BIBFRAME administrative metadata templates, which were nested in WEMI templates and themselves included nested templates for things like Status and GenerationProcess (see "2019/2020 WAU BF AdminMetadata resource template" above).

Notes

I have a not-so-hidden agenda to avoid a standalone resource template(s) for administrative metadata. This is based on cataloger feedback from 2019-2020, in which the requirement to work in multiple templates (tabs) to describe a piece in hand was disliked by cataloging staff. The Sinopia UI has improved much and made this navigation easier but I still believe that a user must move from tab to tab to enter statements in different standalone resource templates, whereas values may be entered in a nested template (even, I believe, a nested template with multiple levels) without leaving the template (tab) which nests that template.

Also tagging MARC2RDA members @gerontakos @CECSpecialistI

[CECSpecialistI]

It is my understanding that blank nodes are not well-formed RDA, and need to be avoided. I think @GordonDunsire may have mentioned this during one of our mapping meetings? I can't find anything in the toolkit or registry to back that up. Either way, I think blank nodes should be avoided wherever possible. Does Sinopia not yet have an option to mint an IRI for a nested resource template? If they don't, they should. Whether a template creates a blank node or mints an IRI seems like something that should be left up to template creators. I agree that RDA requires both works and expressions for descriptions of resource entities, based on my explorations during the PCC RDA Toolkit test. Is a metadata work a resource entity? Or something else? It doesn't make sense to me to make a metadata work into multiple entities. Are there properties for metadata expressions? I think if we're going to use any blank nodes anywhere, this would be the place. It might be nice to have URI's for our metadata description sets at some point, though, don't you think?

[GordonDunsire]

@CECSpecialistI is correct that blank nodes have been mentioned in MARC2RDA mapping discussions, and that my advice is to avoid them. I was asked for more explanation by a specific library and this is what I said:

= = =
Blank nodes do not conform to "well-formed RDA" metadata; see the Toolkit guidance.
 
Specifically, a well-formed RDA metadata statement should have a subject that describes an instance of an RDA entity, but a blank node only indicates existence, not identity, and 'describes' nothing. A well-formed RDA metadata description set should only contain well-formed metadata statements, and this is what prevents the main utility of blank nodes.
 
The main reason is that RDA is intended for a high degree of re-usability in open linked data applications. A locally-created metadata description set (i.e. RDF graph) is most re-usable if all of its sub-graphs (sub-sets and individual statements) can be re-used.
 
The use of blank nodes in bibliographic metadata seems to be a result of transforming legacy metadata (primarily MARC 21 encoded AACR/ISBD) for re-use in 'record exchange' environments. There was/is a reluctance to mint IRIs (a blank node is a cheap way out) for what RDA calls a superelement (e.g. publication statement). Typical legacy (mainly ISBD) applications use the element to 'bag' or associate finer-grained elements (place and date of publication, publisher) when a manifestation may have more than one such 'statement'. Typical legacy transformations use blank nodes to relate the finer elements to the statements.
 
This is not necessary with RDA/LRM. The finer elements are recorded in context in new "manifestation statement" elements; the publisher, place, and ate are transcribed as they appear in the manifestation, and form a significant part of the descriptive metadata. The finer component values are also normalized (under authority control, etc.) and recorded as relationship elements for navigation and access, and for linked data.
 
The use of blank nodes restricts open re-use of the RDF statements. We have discussed this several times in the MARC2RDA*** meetings, but in different contexts and often in side-discussions ;-)
 
*** It is, after all, legacy metadata ... the tension is between producing well-formed RDA vs lossiness of the transformation
= = =

Some points are missing from the discussion in this thread:

1. There is a latent assumption in RDA Toolkit that a blank node is not an IRI, so all references to using an IRI assume that a blank node is excluded.
2. The "minimum description" guidance is intended for all four RDA implementation scenarios, and the method of identification of component resource entities in a "resource description set" is given in the guidance on RDA implementation scenarios. For scenario A (Linked open data), "A metadata description set for an entity is linked to a metadata description set of a related entity using an IRI of the related entity." Given that all relationship elements have inverses, it is assumed that "IRI of the related entity" applies both ways.
3. As @pan-zhuo mentions, an RDA metadata description set is defined as "A metadata work that is an aggregating work that is a plan to select and arrange one or more expressions of one or more metadata statements that describe one or more individual instances of RDA entities and embody them in an aggregate. The plan may be part of an application profile." In general, it is not necessary to describe or mint an IRI for an aggregating expression, and the only expression properties that can be used are appellations. Instead, the metadata/aggregating work is related directly to its manifestation. I think a good design pattern for well-formed RDA administrative metadata/data provenance is to mint an IRI for the metadata work, stringify the IRI to create the required identifier for work, and relate the work to its manifestation. This can't be done with a blank node = empty string.
4. Any change to a metadata statement in the manifestation of a metadata/aggregating work requires a new metadata work, according to RDA's implementation of the LRM model of aggregates. In linked open data, an update to a metadata statement should result in a new metadata statement and the deprecation of the original statement. This changes the set of metadata statement expressions that have been aggregated in the description set, which is a change of aggregated expressions, which is a change of metadata/aggregating work. This has general ramifications for "fixed" aggregations that are published in multiple editions with augmenting expressions (e.g. an introduction), and discussion is ongoing in RDA communities about resolving the issues by extending RDA properties. Some of this will be applicable in due course to data provenance/administrative metadata (or vice-versa).
5. The RDA treatment of data provenance is intentionally broad and restricted to the re-use of existing RDA properties (and entities). RSC expects RDA communities to develop more specific treatments, possibly invovling RDA refinements (sub-typing of existing properties) and extensions (adding "sibling" properties), and has put in place a mechanism (Community Resources) to a) share such work with other communities and b) allow RSC to monitor usage, etc. to determine if a refinement or extension should be incorporated into 'base' RDA.

[briesenberg07]

Clarifying requirements

Thank you @pan-zhuo @CECSpecialistI @GordonDunsire all for the comments. @GordonDunsire I'd like to confirm and clarify my understanding of requirements for these templates based on your comments.

IRIs (not b-nodes) for all administrative metadata resources

All administrative metadata templates will need to be 'standalone'*, not 'nested resource templates'**.

• * My term for a Sinopia resource template which mints an api.sinopia IRI for the resource described.
• ** A Sinopia term for a resource template which appears within another resource template. This feature eliminates the need for tab-switching, but at present resources described by nested resource templates are assigned blank nodes. (Sinopia docs for nested resource templates don't state this explicitly but it can be confirmed by a simple test [1].)

Two (2) admin metadata templates: Work and Manifestation

I think a good design pattern for well-formed RDA administrative metadata/data provenance is to mint an IRI for the metadata work, stringify the IRI to create the required identifier for work, and relate the work to its manifestation.

• I take this as guidance to create and use administrative metadata Work and administrative metadata Manifestation templates.
• This guidance suggests that requirements for minimum description of a work be met by using P1002 (has identifier for work). Work template would also include P10072 (manifestation of work).
• Other properties to include in the Work and Manifestation templates are yet to be determined. If we are still thinking about sharing converted BIBFRAME, ensuring that RDA elements in the admin metadata templates can provide the data needed for reasonable BF adminMetadata could inform selection of elements. Other resources which should be consulted when selecting elements for the templates are... Not in my mind at time of writing.

[1 - nested template = blank node]

data entry

output preview

[GordonDunsire]

Here is a generic model for metadata provenance in RDA:

I have used the broadest classes and properties; e.g. Agent instead of Person.

I hope this helps.

[briesenberg07]

Thanks for sharing this @GordonDunsire ! Much appreciated.
I hope to share draft-version metadata provenance templates here for feedback soon.

[pan-zhuo]

Some thoughts on metadata works, specifically metadata description sets:

1. Since metadata description sets are aggregates, there are no 'author agents' for a metadata description set as a whole. Creators of a description set are 'aggregator agents', and creators of individual statements are 'contributor agents of text' in the context of describing a description set as a whole. I suppose in most cases the two types of creators are the same, i.e. catalogers?

2. The language and script used for creating a description set will need to be recorded as 'language/script of representative expression', if no metadata expression is identified.

3. Could metadata description sets be considered as diachronic works, specifically integrating works? Think about serial cataloging, the 'records' are periodically modified or 'replaced', aren't they? The caveat is that different RDF serialization formats will be considered as distinct works rather than expressions because of the WEM lock...

[GordonDunsire]

@pan-zhuo:

1. This is correct. Furthermore, "aggregator agent" and "author agent" are both subtypes of "creator agent", so in the case of it being the same agent, the broader "creator" relationship is ok.

2. Yes. In general, there is no use case for describing the aggregating expression of a metadata description set. Also, common attributes in the aggregated expressions (metadata statements) are always recorded as representative expression work-level attributes.

3. Yes. I am working through the detail of how a hybrid aggregating/integrating work is described to be consistent with aggregating works and diachronic works. Preliminary conclusion is that there is no use case for describing the aggregating/integrating expression ...

[briesenberg07]

Metadata W + M to do

• Ensure compliance with minimum description of a Work and Manifestation
  • need an appellation for each
  • this also requires linking from work to manifestation (not vice versa?)
• Identify additional needed data-provenance information / use Toolkit guidance > data provenance as source of these elements)
  • Content standard (included in 2019/2020 bf:AdminMetadata template)
  • Metadata publisher (included in 2019/2020 bf:AdminMetadata template)
  • Language of description (included in 2019/2020 bf:AdminMetadata template)
• Configure date properties for metadata W + M -- this may require resolving discussion of metadata description sets as diachronic works above?

[briesenberg07]

See meeting notes from 2023-05-02 for some discussion of the above to-do items.
Note @pan-zhuo prefers lookup PTs for entering metadata Work and Manifestation IRIs.

[briesenberg07]

Data-provenance information which needs to be recorded at the statement level

It seems to me that the following data-provenance information--if needed--would only be applicable at the metadata-statement level. How to record this information, if needed?

• String encoding scheme - see the option to record this as related work of work
• Transcription standard - see the option to record this as a related manifestation of work
• Recording source - multiple values at the description-set level might be of some use; would make the data-provenance entry (even more) burdensome - see the many options which fall into two categories:
  • source of metadata Work is a manifestation being described
  • source of metadata work is not a manifestation being described