Explore modeling controlled vocabularies as taxonomy terms

[dannylamb]

From the March 14th CLAW Call:

Using the taxonomy module to tag content with terms from controlled vocabularies could be used to alleviate the administrivia involved with managing a large number of content types with their associated fields. This would break the restriction of one rdf mapping per content type, as well most other site functionality. This means we'd be using terms to dictate functionality, for which there are plenty of third party modules available.

It seems like a slam dunk, but there are some considerations we'll have to hammer out first. Most notably that terms are generally considered local, though we'd want them to reference the uris present in the controlled vocabulary we're using. We'd also have to figure out how we can enrich our RDF with enough information derived from the terms so that information gets persisted in Fedora. Most likely this means we'd be adding one or more rdf:types to our jsonld based on what taxonomy terms a node is tagged with.

FYI, we'll probably get a lot of mileage out of this: https://www.drupal.org/project/term_condition Aren't plugins beautiful?

[mjordan]

@dannylamb isn't Context beautiful... well, at least super useful.

[seth-shaw-unlv]

Edit: I just realized that my comment below is related to, but tangential from, this issue. Sorry!

Trying to wrap my head around this, so I may be way off base, but let me see if I'm reading this right...

Currently we have a content model that stores descriptive metadata as part of the node with media entity references for each of the file representations (tiff, th, web_content, etc.). This is serialized into json-ld with the help of RDF Mappings and serves as the basis for what Fedora 4 receives and stores.

With context: would have a suite of fields available, not necessarily associated with any particular content type/bundle, but with a taxonomy term context that would trigger their availability for a given node?

For example, I have this node with the taxonomy terms "image" and "dublin core" applied to it, so magically that node would then have the fields corresponding to each taxonomy term? (E.g. a tiff media entity reference for the image term and dc:date and dc:extent for the dublin core term.)

Is that a correct characterization or am I misunderstanding how context would be used?

[seth-shaw-unlv]

Or is it more something like this: we have a generic islandora object with a media entity reference and a descriptive metadata reference. A node stores references to the relevant media entities and descriptive metadata entities (each media type or metadata profile would be their own content type). The Context module would control which types of media or metadata profile entities displayed in the UI and would also control whether the JSON-LD imported the linked entity fields into the JSON-LD (for metadata profiles) or used a reference (for media entities).

Diagrams to illustrate how I am thinking about these...

How we do it now:

How we would do it with Context:

Feel free to edit the diagrams.

[dannylamb]

I'm looking at the migrate_plus module now from #819, and it contains example migrations that pull in taxonomy terms! Having a framework / template for importing controlled vocabularies would be super sweet.

[dannylamb]

Ah, shoulda reloaded my page! @seth-shaw-unlv So the diagram you've drawn up pretty much nails it. We'd have to use context to expose an alter for merging the metadata nodes into the main node's jsonld. We've actually already done this once to add the Drupal URI to serialized jsonld, and could probably just build on it for more jsonld alterations like this.

As for your first post, the tagging of nodes with taxonomy terms can be used to drive pretty much anything. So things like what what derivatives get triggered, what gets indexed into fedora, etc... can all be configured to based on taxonomy terms instead of content models. And by that I mean you could probably do it right now all through the UI using https://www.drupal.org/project/term_condition.

Looking forward, we could have that final separation of structural metadata, descriptive metadata, and behaviour I've hinted at a few times during calls. We would be able to do things like use a single module with entities/fields for structure(PCDM, ORE, EDM, etc..), a single module for descriptive metadata entities/fields (e.g. a dcterms module with author and location entities), and a single module for driving behaviour using taxonomy terms (islandora_collection, islandora_image, etc...). It'd be all about re-use at that point, and would definitely cut down on the administrivia of having to repeat the same fields over and over again for each content type.

[mjordan]

Just want to make sure we don't lose the link (no pun intended) between this issue and #815. Transmission ended.

[DiegoPino]

This is exactly what i was trying to say here #815 (comment)

Also, in the original JSON-LD module implementation we had the ability to expand referenced entities (any) and make a deep @graph instead. We can reuse the same idea to complement what is missing with the default, flat json-ld? Or even better, let camel sync machinery deal with the full, deeper, graph when syncing to fedora?

[dannylamb]

FYI, yes... we can do this with migrate_plus. We need to write a custom source plugin to download the list of terms from somewhere and parse them... but that's about it. Chances are rdf+xml will be available and we can parse it using xpath.