Resource Relation Metadata

[jkim-ru]

I think we need to discuss the "relation" metadata for Resources more. This issue was created after an email exchange with Ron regarding input from Grace. There may be existing ways of creating a "relation" using already-implemented Hyrax functionality, and I think we should explore whether or not these can be used.

From Grace: "Please be sure to include all the fields a researcher wants to see, about the researcher and the data. This means throw up a CV and a link to a website, whether your departmental or directory page or your linkedIn page. Be sure to include a research hypothesis. Ron, you should include a link to your dissertation (the DOI) if the data is from your dissertation. there is a relation field for that."

For clarification, the most recent metadata spreadsheet provides additional source/usage information as the following: "hasFormat; hasPart;hasVersion;isFormatOf; isPartOf; isReplacedBy; isVersionOf; replaces".

Question 1 -- Should we have a relation field to link internally and externally, and what should that look like? Should it be a simple input form field for external links?

Question 2 -- A vanilla hyrax application has its own file manager for maintaining versions of uploaded works. Do we want to keep that in place? Or, do we want our own?

Question 3 -- There is a way to attach "child" works to a work (though I run into errors when I attempt to use it). Do we want to explore whether or not we can potentially use this?

Question 4 -- Should the CV stay as part of the "long display" for a Person, or should we move it to the "short display" and have it be viewable from a Resource long display?

[jkim-ru]

From Discussions with Grace/Ron/Janice/Chuck:

Resource relationships. We will add another relationship (isReferencedBy) to point to resources external to the VDC (e.g. a dissertation). Grace also indicated that we should add isAnalysisOf. We will also remove the compound element from the metadata profile. As a result, we will need to associate relation URI and type by their ordering. If possible for V1, the user should be able to provide a URL for isReferencedBy so we can demonstrate the referencing of external resources.

[jkim-ru]

I'm planning on doing something simple for now, like adding the following to my resource model:

property :relation_url, predicate: ::RDF::URI(" https://example.org/resource#relationUri"), multiple: true
property :relation_type, predicate: ::RDF::URI(" https://example.org/resource#relationType"), multiple: true

Also, asking the community if there's a better way of doing this. https://groups.google.com/forum/#!topic/samvera-tech/YCGPTUTgxcI

[jkim-ru]

I'm currently thinking that a better solution is to implement an ActiveFedora::Base class called Relation, with attributes uri and type.

Then, when processing a work, I'd have to add jobs/processing to attach a Relation to a work. Upon discussing this with Grace, she mentioned that it seems a bit round-about. Still, I don't have a better solution as of now, so I'm going to try going in this direction and see if I can get it done by the Wednesday deadline.

Also, this may or may not be relevant, but I'm posting here so I don't lose it: https://wiki.duraspace.org/display/samvera/MODS+Individual+Mappings+for+Other+Related+Item+Cases

[jkim-ru]

I'm getting stuck on how to use simple_form_for to take in nested model input (i.e., how to modify the resource form to take in paired relation_type and relation_uri rather than each individually). I'm currently looking at the hydra-editor and trying to investigate if there's a way to modify the javascript to allow this nested model input.

Edit --

Found these potentially relevant links on nested attributes using Sufia, but it's not all fleshed out:
https://github.com/samvera/sufia/wiki/Customizing-Metadata-(Sufia-6):-nested-attributes,-part-1 https://github.com/samvera/sufia/wiki/Customizing-Metadata-(Sufia-6):-nested-attributes,-part-2

Also, got a suggestion from the slack channel to check out UCSB for a potentially working example: https://github.com/ucsblibrary/alexandria

[jkim-ru]

Update -- After meeting with Grace/Ron, it was decided to keep things simple and NOT use complex metadata. The metadata spreadsheet will be updated to reflect this.

[jkim-ru]

After a priorities meeting today, Ron and I will be revisiting this soon. We need to come up with an approach for this, but not necessarily code for now.

[jkim-ru]

Met with Ron yesterday to briefly discuss OAI-ORE and potential mapping of hyrax rdf data somehow to the OAI-ORE model. He pointed me to the following doc to read up more (though he suspects the document refers to Fedora 3, not 4):

http://journal.code4lib.org/articles/1062

I probably won't be able to spend much time on this, but I'm leaving this here for reference. How we define relationships in our works may affect the OAI-ORE model that we're trying to both understand more about and achieve.

[jkim-ru]

Update from Grace/Ron:

We need a simple way to document in metadata related resources, primarily viable versions of resources where each have metadata and resources referencing data, such as an article or a dissertation. We will need dcterms, e.g., hasVersionOf instead of relation.