Reification in the mapping

[gerontakos]

Recommending reification in general seems like an overcomplication of our mapping.
Reifying selected statements based on subfields seems like over-overcomplication.
I would prefer to avoid recommending "layers" of description and as a general rule avoid reification. I think we could do that and still produce useful RDA data from MARC data.
Also, I don't know what reified statements look like in RDA.
I don't recognize this syntax; I believe it's unique to us:
< < > > .
I believe we're talking about creating named graphs then describing the named graphs. So we'd be recommending quads.
I'm almost certain we're not planning on using RDF reification.
Perhaps if we produce an example of something with RDA reification in a modern-day serialization like Turtle, or, if quads are needed, N-Quads, that would help us devise a syntax in the final mapping? It might also help concretize exactly what we're recommending in the mapping/alignment. Or perhaps I'm the only one fuzzy in this area.

[GordonDunsire]

I agree in general with @gerontakos; reification is to be avoided, and its use for data provenance with legacy MARC 21 metadata is very limited because of its imprecise identification of provenance.

Nobody knows what a reified statement (metadata work) looks like in RDA. Additional clarification and complication was made with the development of collection-level description (i.e. catalogues as aggregations of metadata statements). I believe Richard Fritz is working on it with RIMMF4.

[CECSpecialistI]

I imagine reified statements as N-Quads and have a very difficult time imagining any other way to express them. I'm not sure what we can do with $5 or 040 $a/c/d if we don't use reification? Or how we will include provenance information about our transform, which is something we don't have to worry about at this point but will become necessary down the road. Am I missing a big piece of information?

The presentation at NARDAC on Monday about collection-level descriptions as metadata works made me very confused about how to refer to RDF triples as metadata works. Are the new properties "__ described with metadata by" only meant to be used for things like finding aids/catalogues, or can we use them for RDF triples too?

[pan-zhuo]

Could be totally off-base but I'm thinking that "__ described with metadata by" is used at the "record" or description set level?

<http://ex.org/manifestation/123> manifestation described with metadata by <http://ex.org/manifestation/123/about> ;
  title proper "some string" ;
  carrier type "volume" .
<http://ex.org/manifestation/123/about> author agent <https://www.wikidata.org/wiki/Q131454> ;
  source consulted "uwlib marc2rda v.1.0.0" .

The minimum description of a work means we need to link the metadata work to a manifestation/expression.

<http://ex.org/manifestation/123/about.ttl> work manifested <http://ex.org/manifestation/123/about> ;
  publisher agent <https://www.wikidata.org/wiki/Q7896575> .

But still need an expression URI for 040$b? Again, I might be totally wrong.

---

For reification of single statements, I googled around and found the << >> syntax looks similar to RDF-star.
It's designed to simplify describing RDF statements.
https://w3c.github.io/rdf-star/cg-spec/editors_draft.html

Not part of W3C standards at the moment but it looks like they will make a proposal to the W3C?
https://w3c.github.io/rdf-star-wg-charter/

[GordonDunsire]

A description of something may belong to one of two categories:

A 'narrative' description, such as a biography of a person.
A 'metadata' description, such as an authority record for a person.

A narrative description is typically unstructured; a metadata description is structured (the three parts of a metadata statement provide the basic structure, and values are controlled where feasible).

The 'described with metadata by' elements are used for metadata description ("metadata" is always a description of something). The range of these elements is (metadata) Work. A metadata work is a single metadata statement or several metadata statements in a metadata description set.

The domains of these elements are the Entities that are described by the metadata.

exGD is person described with metadata by exWork1 .
exWork1 has manifestation of work https://isni.oclc.org/DB=1.2/SET=1/TTL=1/CMD?ACT=SRCH&IKT=8006&SRT=LST_nd&TRM=gordon+dunsire .

exGD is person described by exWork2 .
exWork2 has manifestation of work http://www.gordondunsire.com/about.htm .

[Might be better to play safe and stringify the ISNI URL; I'm not sure if this is a cool URI or not.]

To map 040$b, we need:

exManifestation1 is manifestation described by exM21ManifestationRecord1Work .
exM21ManifestationRecord1Work has expression of work exM21ManifestationRecord1Expression .
exM21ManifestationRecord1Expression has language of expression {040$b} .
exM21ManifestationRecord1Expression has manifestation of expression exM21ManifestationRecord1Manifestation .

[exM21ManifestationRecord1Manifestation is the manifestation of the metadata work that is produced by applying the map to a MARC 21 bibliographic record.]

[lake44me]

1. ISNI is planning to be cooler with their URIs but does provide some things now. https://isni.org/page/linked-data/ . There interface is pretty ugly right now though. https://isni.org/isni/0000000370670977 leads to a page where you can download some RDF/XML or JSON/LD.

2. Came across this blog post from Hugh Cayless at Duke long ago; seems relevant [https://blogs.library.duke.edu/dcthree/2013/07/27/the-trouble-with-triples/] . Unfortunately the solution he proposes (creating a URI/urn identifier for each triple based on a SHA1 hash of the triple) doesn't seem to have gotten much traction, although the company he mentioned (Datomic) appears to be still in business. I don't know enough to critique this from a technical angle but it sounded great.

Might be interesting to think about what we could do with RDA mapping (or expansions on the RDA vocabularies) if we had triple IDs available.

[GordonDunsire]

Cayless essentially describes the quads that we have discussed: every triple in the store is assigned a URI (the fourth element). Much work has been done since 2013 on RDF graphs, for example SHACL, but the underlying issues of reification remain. Cayless is concerned about scalability (but that's what they said about full-motion computer-generated moving images, aka video games). I'm not sure why a hash of the triple was proposed, unless it was to prevent multiple different reifications of the same triple; I assume that in practice most refication will be done by the publisher of the triples in the first place, and a simple quad 'running number' URI is sufficient.

[lake44me]

So, the example I am developing for tag 561 seemed to me to be the only "legal RDF way" to describe a reification, until rdf-star gets adopted (crosses fingers). I did this example as statements, one triple at a time; there were only two subfields to map, but is there a way to reify multiple triples as a group that would be more efficient?

[GordonDunsire]

For more than one triple, we have to use 'named graphs' for reification.

[szapoun]

As promised, here is what we are doing at the NLG with notes.

1. Create items in the wikibase for each note type we need. In the following example this is the wikibase item for Internal note

2. Create the property that will be used as qualifier. We selected the "nature of statement [wikidata/item] (P5102)"

Example 1. Internal note

Example 2. Source consulted
Here we used the rdau:P61101 "has source consulted" and 2 qualifiers. The rda property takes $a as value, while the qualifiers are used for the $b and $u values.

[lake44me]

This is mapping MARC21 Authority Format, but looks like the approach would be applicable to bib data. It would be helpful to see RDF output utilizing these qualifiers - I'm having trouble visusalizing what the subject of the triples would be..

[GordonDunsire]

I'm not sure if this is the right place, but attached is my strawman document on reifying entity instances. This is distinct from reification of statements, and might be better in a different thread; feel free to move it.

Reification of MARC 21 Bibliographic records.docx