Create an 'Agent' content type

[dannylamb]

Blocked by #893 and #889

Using https://docs.google.com/spreadsheets/d/18u2qFJ014IIxlVpM3JXfDEFccwBZcoFsjbBGpvL0jJI/edit#gid=0 for guidance, make a new content type for 'Agents' (you can name it whatever we collectively feel is best, we're not beholden to 'Agent') to be populated from MODS name elements. You'll want to make the 'role' field a taxonomy term reference to the MARC Relators vocabulary created in #893. You'll also want the relator term chosen to dictate the rdf:type of the 'Agent', so you'll also need to wait for #889.

[DigitLib]

Signed!

[rtilla1]

Sprint Kick-off: Similar to #894 . Should be fairly straightforward.

[rosiel]

To explain the MIG's spreadsheet, the section called "Minted Elements: Name" lists some fields that we'd like to be able to model - as these are names coming from MODS, we'll want some namePart equivalents as well as a "displayForm". Yes - potentially duplicating data.

[seth-shaw-unlv]

I humbly submit this module as the basis for Agents. It includes content models for Corporate Body, Person, and Family.

[DigitLib]

@seth-shaw-unlv TNX!! so we can use it to expand it according a doc?

[seth-shaw-unlv]

Yes. I'm not tied to anything in that module. I would prefer we add the module as an islandora demo dependency, then we can issue PRs against that repo. (I would like to keep it a distinct repo because I am using it in another project too.)

Also, if the Islandora community would like, we can simply transfer the repo to Islandora.

[DigitLib]

@seth-shaw-unlv we'll see what @dannylamb has in mind for this it would be goo to have a module for this with a defined RDF

[dannylamb]

@seth-shaw-unlv That is a great starting point for agents. We might want to take this as an opportunity to do some housekeeping. We could break the demo feature off into its own github repo and either roll in the config from controlled_access_terms or export it as a separate feature but put it in the same repo.

Then whatever applicable code is in controlled_access_terms should probably get rolled into the core islandora module.

[seth-shaw-unlv]

@dannylamb my preference would be

• islandora_demo as a separate repo
• controlled_access_terms as a separate repo, listed as a dependency for islandora_demo so it can be used with the 7x migration content models.
• the new TypedRelation field and related code in the jsonld repo (that way other non-islandora projects can use it)

[dannylamb]

@seth-shaw-unlv I'm pushing through your first two bullet points now. I've left the code in controlled_access_terms, and we can shuffle it out in a PR no prob. Although as it stands right now it looks like controlled_access_terms is totally islandora independent anyway?

[seth-shaw-unlv]

Yes, @dannylamb, I intended it to be independent of islandora because it is also being used in an archivesspace/drupal integration module.

That stated, I'm also trying to keep that archivesspace/drupal project in line with islandora so they can be easily used together.

[dannylamb]

@seth-shaw-unlv I'd prefer to keep it that way too. One of the hardest struggles of this project has been to define the code boundaries. Keeping everything as independent as possible is the way to go.

[dannylamb]

controlled_access_terms satisfies this issue, so closing.