[DOCS] Establish an ontology for maintaining URIs used in core Islandora vocabularies about documentation

[ruebot]

There is this related issue too #1318

[rosiel]

We've done a lot of work making islandora work with whatever URIs you want. That is, the URIs are not in code, they are in config, and the resulting behaviour is also determined by config.

Are you proposing that we start to hardcode, in workbench or other places, behaviours that are currently configurable so that they are no longer configurable?

[mjordan]

No, I am not proposing hardcoding anything. I am proposing that we have an open process for adopting (and documenting) new default URIs when needed so we can choose URIs that will work in a wide variety of contexts.

Within a specific Drupal instance, configuring a local or preferred URI is harmless. If a site admin wants to deviate from the default URI for some reason when the term means exactly the same thing to site A as it does to site B, that's on them (although I'd be interested in hearing the justification for someone changing a default URI for a term provided that the URI wasn't overtly offensive in some way).

Workbench can be configured (in most cases, I'd have to check to see if/where any have been literally hard coded) to use non-default URIs for terms, but Workbench is a tool we have complete control over. The real benefit of using standardized URIs really comes into play with external tools that we have less or no control over, and in repository aggregation, where the aggregators can assume that all (non-locally modified) Islandora instances use a given URI for a given term. I don't understand IIIF enough to provide a specific example, but I can imagine a researcher wanting to use a standard IIIF viewer to compare two versions of the same page, one of which is hosted at an Islandora repository. I doubt the researcher is going to bother to ask the Islandora repo's manager what the URI for the Media Use "transcript" term is.

Related to aggregation is Islandora repositories participating in the broader Linked Data world. But, it's totally possible that literally nobody really cares about that.

Edit: added "and documenting" to my second sentence.

[whikloj]

IMHO.

1. Maintaining the ontology for any URIs generated by the islandora community (specifically any with an islandora.ca domain) is a must as most of the are (as Mark mentions) the "External URI" field. So they should be a resolvable URI.

2. The idea of adding and deprecating URIs, seems a little odd to me. Mostly I'm unclear on how "we" (being the community) decide what "...lose traction within the larger GLAM community." But as long as we are just deprecating but continuing to make the URI resolvable, then this is more of a "why" than a "how" question. So it can be an evolving process.

3. However, all code can only use these as default values and (I would suggest) in most cases (i.e. for a new module installed in an existing setup) we should look at existing configurations to find the appropriate values.

   In other words, no one should be expecting an URI defined in the Islandora ontology to exist anywhere in a repository but instead should be querying the appropriate configuration entities and/or requiring the setting of configuration for individual tools.

   This means you might have duplicate configuration settings but also allows for that separation and flexibility already built in.

These opinions are my own and only worth the paper they were written on. What's paper you ask? Oh children gather around and let me tell you of the joys of tractor-feed perforations.

[mjordan]

@whikloj a plausible example of a term that is likely to "lose traction" for EDI reasons (and that we currently use as a default in the Media Use vocabulary) is http://pcdm.org/use#PreservationMasterFile.