ArctosDB / arctos

Arctos is a museum collections management system
https://arctos.database.museum
Apache License 2.0
59 stars 13 forks source link

Other ID - host parasite weirdness #6878

Open DerekSikes opened 9 months ago

DerekSikes commented 9 months ago

Yesterday I made a clone of UAM:Ento:488199 to represent a parasite on a host relationship and then made other identifiers to link the two as host-parasite.

I've not done this since the other identifiers remodel. I ran into some problems:

1) Now I select 'UAM: University of Alaska Museum' as the ID type. But do I enter the entire GUID in the 'prefix or string' field or do I break it into prefix (of UAM:Ento:) and integer (492916)? I tried it both ways and both seem to work but that's some strange UI uncertainty and inconsistency. I suppose this has always been a problem even before the remodel. It would be good if this inconsistency was not allowed, but this is a minor issue compared to the next two since it doesn't seem to affect functionality as far as I can tell (but maybe Dusty knows otherwise):

2) When I am in the host record (UAM:Ento:488199) I create an other identifier for the parasite (UAM:Ento:492916) and I choose "parasite of" because the new GUID UAM:Ento:492916 I am describing is the parasite of the host record I'm in.

But when I look at the host record: https://arctos.database.museum/guid/UAM:Ento:488199

the UI displays this as

parasite of UAM:Ento:492916

which is backwards, the NEW IDENTIFIER is what we were describing when we made it. We enter parasite GUID other ID and tell Arctos this NEW other ID is a PARASITE. It is horrible UI to enter a GUID and then expect people to use a qualifier for a DIFFERENT GUID (the host). The other ID is what we are describing not the original ID.

The UI should display as

UAM:Ento:492916 parasite of

on the host page https://arctos.database.museum/guid/UAM:Ento:488199

and to be really unambiguous it should say

UAM:Ento:492916 parasite of UAM:Ento:488199

and this makes UI sense: New GUID / What the New GUID means / Original GUID

and then on the parasite record:

https://arctos.database.museum/guid/UAM:Ento:492916

the other ID should say

UAM:Ento:488199 host of UAM:Ento:492916

3) When I am in the host https://arctos.database.museum/guid/UAM:Ento:488199

and I click the 'search' button next to the parasite other ID expecting to be brought to the parasite record Arctos does a search and brings me back to the HOST (where I started).

The same problem with the parasite - when I'm in that record & click search on the other ID host I am presented with the parasite record again. To get to the correct record I have to copy the GUID and paste it into the search form.

Priority Please assign a priority-label. Unprioritized issues gets sent into a black hole of despair. high

dustymc commented 9 months ago

select 'UAM: University of Alaska Museum'

You shouldn't, that should not exist, @mkoo help! "Identifier" is the correct type.

good if this inconsistency was not allowed

Amen, but we seem unable to reconcile and finish up. Highly recommend just avoiding the existing clutter, identifier and preparator/collector numbers are the only useful types.

enter the entire GUID

Yes, and the GUID is eg https://arctos.database.museum/guid/UAM:Ento:488199 - "DWC triplets" can only be useful locally and there they're just confusing. https://github.com/ArctosDB/arctos/discussions/5310

really unambiguous it should say

We have moved around on that a few times, and I think things have just continually become more confusing. The model is "identifier references" - in the host record, the identifier references the 'parasite of' the existing record.

'search' button

It's doing crazy things because the identifiers are a mess.

Let me know if you want me to fix up the records.

DerekSikes commented 9 months ago

I will reiterate that this:

The model is "identifier references" - in the host record, the identifier references the 'parasite of' the existing record.

is massively counter-intuitive and if we are to force users to do the OPPOSITE of what any normal person would assume then we must MAKE THAT SUPER CLEAR in the UI so users know they should do the opposite of what they were about to do.

I can fix these two records, maybe.

dustymc commented 9 months ago

MAKE THAT SUPER CLEAR in the UI

Please, tell me how! I can't seem to find any of the issues which have rearranged that form, there have been a couple, I agree it's not clear, I would prefer "Relationship" to be labeled "references" (which I'm sorta-sure someone has disliked before, so HELP!). I am completely open to about anything (as long as it retains functionality), labeling, inverting the model, that clever thing I haven't thought of, WHATEVER.

DerekSikes commented 9 months ago

If we are choosing 'parasite of' then immediately PRIOR to that term should be GUID of the existing record in UI.

So it looks like this:

sourcerecordGUID [choose "parasite of" from menu] NEWOTHERIDGUID

and this should be in the form where one enters the newotherID

Jegelewicz commented 9 months ago

which is backwards,

This has always been an issue? https://github.com/ArctosDB/arctos/issues/3394 https://github.com/ArctosDB/arctos/issues/3426

We could use the reciprocals that are more clear

parasite of has parasite

like GloBI does, but that means adding two relationships because you also need

has host host of

where parasites are concerned?

dustymc commented 9 months ago

Thanks for finding those issues.

like GloBI does

AFAIK that's not a good model comparison, globi doesn't have a need to make blind relationships.