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

Update to match latest Islandora Defaults #25

Closed
wants to merge 2 commits into from

Conversation

noahwsmith
Copy link
Contributor

Two contexts need updating:

  1. Remote Video URI for Video term needs to be http://purl.org/coar/resource_type/c_12ce
  2. Collection Context needs two unique URIs (http://purl.org/dc/dcmitype/Collection#Model is one, and http://purl.org/dc/dcmitype/Collection is the other)

@noahwsmith
Copy link
Contributor Author

Ok, the first one is handled here. The second one is correct in the context but the default terms come in from elsewhere - tracking this down...

@noahwsmith
Copy link
Contributor Author

Model comes from https://github.com/Islandora/islandora/blob/2.x/migrate/tags.csv
And Resource Type comes from https://github.com/Islandora/islandora_defaults/blob/2.x/migrate/tags.csv

@rosiel we need to change the URI on the two "Collection" items to be unique. Do you have a preference?

@noahwsmith
Copy link
Contributor Author

At Born-Digital we use Collection#Model for the Resource Type on a dozen or so sites and that should work perfectly with this codebase.

@rosiel
Copy link
Contributor

rosiel commented Jul 28, 2022

My opinion on that is that you shouldn't make users jump through extra hoops and constraints for fun. Last i checked, there was nothing that resource type + model could do that model couldn't. See #11

If you really need another one (whyyyyy please stop making puzzle box software) then http://purl.org/ontology/bibo/Collection would be good.

@noahwsmith
Copy link
Contributor Author

I'm not sure what "puzzle box software" means, so I can't comment on that.

The situation we're trying to fix is that Islandora/Drupal Context looks up taxonomy terms by URI, assuming they are unique, because there is a high probability that you will have many taxonomy terms with overlapping titles. Right now, there are two "Collection" terms in two different taxonomies that use the same URI, which breaks this assumption of uniqueness on URIs, and thus causes a bunch of contexts to fail. We need to set a different unique ID for one of them or rewrite a large portion of how contexts are used to pick view modes in Islandora. I am proposing we make the small change now, and perhaps the larger change (if necessary) will come in the impending refactor.

This is only an issue suddenly/now because the Install Profile has stopped using its own tags (which fix this issue) and is using the Islandora Defaults tags (as it should).

I'm hesitant to change anything in islandora/islandora, so I recommend we change the URI for the Resource Type
https://github.com/Islandora/islandora_defaults/blob/2.x/migrate/tags.csv

I'll go ahead and make that MR and link it here.

@noahwsmith
Copy link
Contributor Author

@alxp merged that islandora_defaults MR (thank you Alexander!)

@rosiel
Copy link
Contributor

rosiel commented Jul 29, 2022

My opinion on that is that you shouldn't make users jump through extra hoops and constraints for fun. Last i checked, there was nothing that resource type + model could do that model couldn't. See #11

That explains "puzzle box software". Unless things have changed since I looked at the contexts in the install profile, resource type is superfluous. The same conditions can be generated with field_model alone. The instant the MIG looked at the install profile, there was a general "WTF" for having two required type-like fields.

What is your use case for doing different things based on different values of "Resource type" and the same value of Field model? Is it worth the confusion that will result if someone sets those values to things that are "not aligned" with the specific combinations that trigger reactions?

Using two fields is a bad solution. The documentation suggests that you can create additional entries in field_model's taxonomy if you need. As for "rewrite a large portion of how contexts are used to pick view modes" - no, i'm just suggesting taking out resource type from the contexts.

What I hate about this software is there are SO MANY PLACES where the user has to dance "just so" and set things as Islandora wants them, or else nothing will work (and chances are they won't be able to tell). This is one of them.

@noahwsmith
Copy link
Contributor Author

I would also like a simpler Islandora, and if all the right taxonomy terms are now in Model, maybe we can refactor all the contexts to just use that. I saw your MR to eliminate Resource Type but it didn't include the rebuild of all the contexts/etc so Islandora would keep working. Maybe there's some hack time next week to work on getting that refactor done, tested and merged when a bunch of us are at UPEI?

@noahwsmith
Copy link
Contributor Author

#11 now makes this obsolete - closing

@noahwsmith noahwsmith closed this Aug 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants