Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

561 ownership and custodial history #225

Closed
CECSpecialistI opened this issue Nov 25, 2021 · 13 comments
Closed

561 ownership and custodial history #225

CECSpecialistI opened this issue Nov 25, 2021 · 13 comments
Assignees
Labels
5XX MARC fields from the 5XX spreadsheet asynchronous discussion needed coded-rft field in category "ready for transform" with coding complete for this level; may need review spreadsheet section assignment issues that reflect progress and provide general discussion space for sections of mapping work
Milestone

Comments

@CECSpecialistI
Copy link
Collaborator

https://github.com/uwlib-cams/MARC2RDA/blob/main/Working%20Documents/5XX.csv

@CECSpecialistI CECSpecialistI added spreadsheet section assignment issues that reflect progress and provide general discussion space for sections of mapping work 5XX MARC fields from the 5XX spreadsheet labels Nov 25, 2021
@CECSpecialistI CECSpecialistI added this to the PCC RDA BSR milestone Nov 25, 2021
@SitaKB SitaKB added the 00X MARC fields from the 00X spreadsheet label Jan 7, 2022
@CECSpecialistI CECSpecialistI removed the 00X MARC fields from the 00X spreadsheet label Jan 26, 2022
@lake44me lake44me self-assigned this Aug 26, 2022
@lake44me
Copy link
Collaborator

lake44me commented Sep 7, 2022

This note is challenging because of the possible value "0" (Private) in ind. 1. Otherwise, straightforward in that we can only map the main content subfield $a to "note on item" (and mint an IRI for item asssociated with the manifestation).

My thought is, since the "private" designation applies only to the note, the note needs to become a "metadata work" so we can say something about it.
Would something like this work? Other possibilities? (this is a transformation note for $a mapping)
*Create a set of reified triples derived from this MARC tag. Included in that set,
mint item IRI and associate with manifestation (has exemplar of manifestation

  • ex: manifestationIRI rdamo:p30103 ex:itemIRI
  • ex:itemIRI rdaid:p40028 "contents of subfield a"
  • Assign a (metadata) work IRI to this set of triples
  • (give it an appellation)
  • Associate the (metadata) work to the minted item IRI using property rdaio:P40164 item described with metadata by
  • Associate a (metadata) manifestation IRI to the work IRI using property rdawo:P10072 has manifestation of work
  • (give the (metadata) manifestation an appellation
  • Associate a value to the manifestation using property http://rdaregistry.info/Elements/m/P30145 restriction on access to manifestation. This could be unstructured string "Private", or preferably a value taken from a value vocabulary if one can be found that conveys the meaning.
    This is clunky - currently there is no property for a metadata work that indicates access restriction, but there's no direct path to a "metadata manifestation".

Wonder if this is the only tag with such an indication in an indicator or elsewhere about restrictions on letting people access it.
@CECSpecialistI @GordonDunsire

@lake44me
Copy link
Collaborator

'Example of reified mapping of tag 561 if Ind1 = 0 (Private)

ex:Item1 rdaio:P40049 ex:Manifestation1 [has manifestation exemplified]
[... if subfield 5 is present, relate item to owning institution etc. per that mapping]

ex:Item1 rdaio:P40164 ex:MetaWork1 [is item described with metadata by]

ex:MetaWork1 rdf:type rdf:statement .
ex:MetaWork1 rdf:subject ex:Item1
ex:MetaWork1 rdf:predicate http://rdaregistry.info/Elements/i/P40026 [has custodial history of item]
ex:MetaWork1 rdf:object "[contents of 561 subfield a (literal]" .
ex:MetaWork1
ex:MetaWork1 rdawo:P10078 ex:MetaManifestation1 [manifestation of work]
ex:MetaManifestation1 rdamd:p30145 "Private" [restriction on access to manifestation]

ex:Item1 rdaio:P40164 ex:MetaWork2
ex:MetaWork2 rdf:type rdf:statement .
ex:MetaWork2 rdf:subject ex:Item1 .
ex:MetaWork2 rdf:predicate http://rdaregistry.info/Elements/i/P40026 .
ex:MetaWork2 rdf:object "[contents of 561 subfield u (uri) as a literal]" . //??? not sure if it can be the URI itself inside this reification
ex:MetaWork2 rdawo:P10078 ex:MetaManifestationw [manifestation of work]
ex:MetaManifestation1 rdamd:p30145 "Private" [restriction on access to manifestation]'

@lake44me
Copy link
Collaborator

Please review, suggest better ways if possible...
Note that rdam: p30145 "restriction on access to manifestation" only accepts an unstructured description.
Could we use rdaw: p10004 "Category of work" and devise a category for a Metadata Work that designated its intended consumption? or possibly some other Work property?

I'd rather there was a controlled value meaning "private" somewhere we could plug in but can't find one.

@GordonDunsire
Copy link
Collaborator

Please note that there is a proposal to be discussed by RSC later this month which will allow rdam:P30145 to accept a structured description/VES. The proposal is likely to be accepted, and be incorporated into RDA early in the new year.

@GordonDunsire
Copy link
Collaborator

However, rdam:P30145 is not the appropriate property to use. As the example shows, it is a manifestation property, but the 'private' restriction applies to the metadata work and all of its expressions and manifestations. I agree that rdaw:P10004 is better, and there is no need to mint the metadata manifestation. The values of 'category of metadata work' are, in this context, binary: private or public?

The status of private vs public is related to other statuses that an RDF graph (metadata work) might have, such as "deprecated". Note that the Open Metadata Registry has a vocabulary of statuses for VES concepts. The status of RDF graphs must be an issue for linked data communities ... but I can't immediately find an appropriate resolution.

@lake44me
Copy link
Collaborator

Thank you Gordon. I'm glad you see 'Category of work" as the better option, and just use the term unstructured. If we come across a VES that has a concept that comes close (private, not for publication, etc.) we could see whether we wanted to use it later. I don't know if this is the same as a status. I'd consider "not published" to be a status, but statuses can change. This should be a value somewhere that a system could use to prevent something's status from ever becoming "published".

@lake44me
Copy link
Collaborator

'Revised example of reified mapping of tag 561 if Ind1 = 0 (Private)

ex:Item1 [mint item] rdaio:P40049 ex:Manifestation1 [has manifestation exemplified]
[... if subfield 5 is present, relate item to owning institution etc. per that mapping]

ex:Item1 rdaio:P40164 ex:MetaWork1 [is item described with metadata by]
ex:MetaWork1 rdf:type rdf:statement .
ex:MetaWork1 rdf:subject ex:Item1
ex:MetaWork1 rdf:predicate http://rdaregistry.info/Elements/i/P40026 [has custodial history of item]
ex:MetaWork1 rdf:object "[contents of 561 $a a plus any addition from $3 (literal]"] .
ex:MetaWork1 rdawd:P10004 "private" [category of work]

ex:Item1 rdaio:P40164 ex:MetaWork2
ex:MetaWork2 rdf:type rdf:statement .
ex:MetaWork2 rdf:subject ex:Item1 .
ex:MetaWork2 rdf:predicate http://rdaregistry.info/Elements/i/P40026 .
ex:MetaWork2 rdf:object "[contents of 561 $u (uri) plus any addition from $3 as a literal]" .
//note: although $u is defined for 561, rdai:P40026 permits only unstructured or structured literal strings.
ex:MetaWork1 rdawd:P10004 "private" [category of work]`

@lake44me lake44me moved this from In Progress to Awaiting Review in MARC21 to RDA-RDF Mapping Oct 19, 2022
@pan-zhuo pan-zhuo added the coding-ar field in category "awaiting review" with transformation coding in progress label Nov 22, 2022
@pan-zhuo
Copy link
Member

I wonder what is achieved by mapping $u separately, when RDA does not allow recording IRIs for rdai:P40026 "has custodial history of item". Seems to me that $a and $u can be joined using a boilerplate:

ex:Item1 rdaid:P40026 "[$a] (Additional information can be found at $u)"

$u is repeatable, so right now in the code I'm doing reification multiple times.

<< ex:Item1 rdaid:P40026 [$a] >> rdawd:P10004 "Private". // Reified statement 1
<< ex:Item1 rdaid:P40026 "http://fakeIRI2.edu/fake1" >> rdawd:P10004 "Private". // Reified statement 2
<< ex:Item1 rdaid:P40026 "http://fakeIRI2.edu/fake2" >> rdawd:P10004 "Private". // Reified statement 3

I'd really like to cut down on the number of reifications needed. $u here is just a text string anyway.

pan-zhuo added a commit that referenced this issue Nov 22, 2022
@pan-zhuo pan-zhuo added coded-ar field in category "awaiting review" with coding complete for this level; to be reviewed later and removed coding-ar field in category "awaiting review" with transformation coding in progress labels Nov 22, 2022
@CECSpecialistI
Copy link
Collaborator Author

I think @pan-zhuo is right; nothing seems to be gained from separate statements for a $u if that is just going to be a string. Reification to say something is private seems reasonable to me, though.

@gerontakos
Copy link
Collaborator

My opinion is that it doesn't matter much either way. I would consider that we conceived of this as a practice run, a demonstration of how to perform reification in RDA/RDF. So I would choose the demonstration that serves better as a demonstration, which I would say is "reification multiple times." But really I don't think it matters too much; either way, we make a good demonstration.

I'm confused about the use of rdawd:P10004; specifically, I'm most confused that a Work property would be used. How could the metadata WORK be private? Isn't the metadata Manifestation private? (Sometimes ubiquitous WEMIfication seems like a tremendous burden.) Then, on a related issue, I'm wondering how "private" can be considered a category for a Work. I don't see the public/private categorization is pertinent to works, so if the value "private" remains related to the metadata Work, wouldn't it make more sense as a mere note?

@pan-zhuo
Copy link
Member

How could the metadata WORK be private? Isn't the metadata Manifestation private?

This reminds me that the minimum description of a work must include a link to an expression or manifestation. Apparently, we are not interested in the metadata expression (unless we want to talk about the language used in the metadata description), then we will need to mint a metadata manifestation anyway, is that correct?

If so, what does that manifestation IRI look like? Suppose you have a metadata work IRI

http://fakeIRI2.edu/MetaWork1

Is the manifestation IRI

http://fakeIRI2.edu/MetaMan1

Or,

http://fakeIRI2.edu/MetaWork1.rdf
http://fakeIRI2.edu/MetaWork1.ttl
http://fakeIRI2.edu/MetaWork1.html

@GordonDunsire
Copy link
Collaborator

@gerontakos: We are talking specifically about a category of metadata work that is a single metadata statement.

We could say that there are two categorization schemes being applied:

  1. Categories of work: static work; diachronic work; aggregating work; collection work (these are all explicit in RDA, but RSC has rightly decided not to offer guidance or vocabularies for "category" elements (one for each Entity).
  2. Categories of metadata work: single statement; multiple statement; public; private; single entity; multiple entity (categories may be combined). A category of "private" would be defined something like "A metadata work that is intended for a closed information system".

@pan-zhuo: For metadata WEM IRIs, we can flip the process I suggested for MARC 21 WEMs:

There is no 'record control number' that can be used as a local part, so we use our own running number (e.g. 1).
Start with Work: exW/1
Add Expression: exW/1 rdamo:P10078 exE/1 .
Add minimal conformance condition for Works: exW/1 rdawd:P10002 stringify(exW/1) .
Add minimal conformance condition for Expressions: exE/1 rdaed:P20002 stringify(exE/1) .
Or: exE/1 rdaed:P20062 "rdf+xml" . // has form of notation

The manifestation of this metadata work is the file that the transform writes to, so we can't mint it ourselves. Note that the manifestation of a set of metadata works is an aggregate of expressions of the metadata works, so it embodies an aggregating work and expression. The aggregating work is the transform because it selects, etc. the metadata works to create, realize, and embody.

@AdamSchiff
Copy link
Collaborator

AdamSchiff commented Dec 7, 2022 via email

pan-zhuo added a commit that referenced this issue Apr 17, 2023
With updates to field 561 #225 &
lookup function for $5
@cspayne cspayne moved this from Awaiting Review to Review in Progress in MARC21 to RDA-RDF Mapping Feb 12, 2024
@cspayne cspayne self-assigned this Feb 12, 2024
@cspayne cspayne moved this from Review in Progress to Ready for Transform in MARC21 to RDA-RDF Mapping Feb 12, 2024
@cspayne cspayne added coding-rft field in category "ready for transform" with transformation coding in progress and removed coded-ar field in category "awaiting review" with coding complete for this level; to be reviewed later labels Feb 12, 2024
@cspayne cspayne added coded-rft field in category "ready for transform" with coding complete for this level; may need review and removed coding-rft field in category "ready for transform" with transformation coding in progress labels Feb 12, 2024
@cspayne cspayne moved this from Ready for Transform to Done in MARC21 to RDA-RDF Mapping Feb 12, 2024
cspayne added a commit that referenced this issue Feb 16, 2024
cspayne added a commit that referenced this issue Mar 25, 2024
working on metadata work IRIs
@cspayne cspayne closed this as completed Mar 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
5XX MARC fields from the 5XX spreadsheet asynchronous discussion needed coded-rft field in category "ready for transform" with coding complete for this level; may need review spreadsheet section assignment issues that reflect progress and provide general discussion space for sections of mapping work
Development

No branches or pull requests

8 participants