Feature Request - make relationships less precise #5349
Comments
|
So can we add the other ID metadata we've requested? Including other ID attributes, and remarks? |
"Eventually" seems like a relatively safe assumption. There's an open request for help over there; I'm stuck against all the seemingly conflicting demands and need some help, but I'm fairly sure we'll (eventually) get through.
That's most of what's driving this; I'm not at all convinced that we as a Community understand our terminology, and it's all downhill from there. This would put the course-enough-to-make-being-wrong-difficult stuff up front, and the gritty details a step further in, where they can be considered after the first pass has been made. So, for something like #1842 the first level might be @Jegelewicz 's
|
|
I concerned that the rest of the world with not understand these
distinctions, given that most people will be looking for "parasite of" or
"sibling of". Can this subtlety be something we keep under the hood?
…On Tue, Dec 6, 2022 at 4:52 PM dustymc ***@***.***> wrote:
* [EXTERNAL]*
o can we add the other ID metadata we've requested
"Eventually" seems like a relatively safe assumption. There's an open
request for help over there; I'm stuck against all the seemingly
conflicting demands and need some help, but I'm fairly sure we'll
(eventually) get through.
fail to be discoverable because no one knows how to interpret our
terminology.
That's most of what's driving this; I'm not at all convinced that we as a
Community understand our terminology, and it's all downhill from there.
This would put the course-enough-to-make-being-wrong-difficult stuff up
front, and the gritty details a step further in, where they can be
considered after the first pass has been made.
So, for something like ArctosDB/arctos#1842
<#1842> the first level might be
@Jegelewicz <https://github.com/Jegelewicz> 's adjacent (they're
touching-ish) and the second layer could
- leave it at that, or
- involve hundreds of hypotheses by hundreds of experts using hundreds
of methods, all referencing relevant methodology and using
discipline-specific terminology (the stuff that we mere mortals won't
successfully penetrate as first-level data) to describe what might be going
on, or
- anything in between
—
Reply to this email directly, view it on GitHub
<#5349 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADQ7JBF2GAFYA7VV3QXRM3TWL7GSHANCNFSM6AAAAAASWCLFHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I'm proposing an idea, not (yet) details.
I sort of assume those would survive as first-level relationships even though that might not be entirely correct and 'sibling' should probably-maybe-theoretically-ideally be accompanied by something involving genetics and 'parasite' should probably-maybe-theoretically-ideally involve someone with enough expertise to exclude hungry wandering fleas. Meh, whatever, I'm more concerned about the ~dozen things (and a request) that all look a bit like 'associated with' from here. (I'm sure "posthumously printed" is important for some specialists, for most of the rest of us something that fine means so many categories that we'll miss some stuff - what I'm proposing does both without conflict.) I suppose the alternate proposal would be to beef up the documentation so that even a dummy like me can understand the differences between series/matrix/lot/set/assemblage/edition/collection. |
|
It sounds like the problematic relationships are to do with the terms used by art/cultural collections. I suppose using an "associated with" relationship would be fine, but it tells me less when looking at a catalog record than the specific relationship. The relationship between three drawings matted together in a single frame is very different than the relationship between three prints pulled from the same matrix. A remarks field to add more specificity could work. In some cases it might be nice to have the flexibility to add free text remarks, while in other cases all that is needed is a term to describe the relationship, which is what the current code table does. |
Not how I'd describe them!
The impact of #4604 is clearly not understood. This could not be implemented before it, and very likely needs adjusted after. It's just an idea that I don't want to lose track of (and so maybe needs filed as such, somehow?).
Maybe, but for all the right reasons. I can say a flea is 'adjacent to' a lynx, someone who can ID the flea might say its probably a parasite of the lynx or not, that's about it. Humans can create vastly many more associations which might change the nature of how we see the objects, and at least some of them are hypotheses which would benefit from determiners and methods and such, or might even be part of a set of maybe-conflicting hypotheses. This is just a way to fully express all of the fine-grained details without them also causing the big picture to become blurry. |
|
@campmlc @DerekSikes @dustymc @krgomez and anyone else interested in relationships, please see and participate in this discussion! https://discourse.gbif.org/t/biotic-relationships-are-reciprocal-relations-needed/3805 |
Yes, for all the reasons spelled out over there. There's often ambiguity, uncertainty, crappy identifiers, etc., etc., etc., involved. Reciprocating provides a confirmation. (Or creating a nonreciprocal relationship - "has nothing to do with plz stop!" - might provide a mechanism for refutation.) This issue would just make it easier for "normal" users (those who might encounter a mite standing on a beetle) to avoid the complexity of being specific, and experts (those who might wish to say something about why that mite is standing on that beetle) to embrace the technical details without making things completely inaccessible to less-expert users. |
|
But also what is clearly spelled out there is the need for relationships that are as specific as possible.... |
Add "without making the users who don't want to wade through that" and you've got precisely what I'm proposing. |
|
I still think this issue and others like it could be solved by some sort of ontology or definitional hierarchy so that multiple terms could map to the same higher category. Allow " associated with" if that's all you know. But parasite of and phoretic on and phoretic host of and same assemblage as etc would all be subcategories of that. And searches of associated with could be broad or narrow, higher category only or including all subcategories. The problem seems to be with our failure to understand and incorporate the fact that these terms themselves have relationships to each other, and to document the level of specificity, and allow for synonyms. |
Those fix all sorts of things in theory; a bit harder to find an example in reality, but perhaps because I don't know where to look.
That's what I'm proposing; think of it like a 2-layer ontology, sorta.
That's not in what I've proposed, might be in an ontology, I'm unconvinced it can be a successful part of any management system. (Certainly valuable for things like aggregators.) I could come around, but I think it would have to be a part of a well-designed plan, not some sort of afterthought. |
|
I remember a really interesting trait ontology talk at the Berkeley idigbio
meeting. Here is something from a Google search of trait ontologies:
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6169674/#__ffn_sectitle
This would be more relevant to our parts table, but the concept seems to
apply for any terms that have a hierarchical relationship to each other.
…On Wed, Jan 18, 2023, 11:00 AM dustymc ***@***.***> wrote:
* [EXTERNAL]*
ontology
Those fix all sorts of things in theory; a bit harder to find an example
in reality, but perhaps because I don't know where to look.
searches of associated with could be broad or narrow
That's what I'm proposing; think of it like a 2-layer ontology, sorta.
and allow for synonyms
That's not in what I've proposed, might be in an ontology, I'm unconvinced
it can be a successful part of any management system. (Certainly valuable
for things like aggregators.) I could come around, but I think it would
have to be a part of a well-designed plan, not some sort of afterthought.
—
Reply to this email directly, view it on GitHub
<#5349 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADQ7JBFC5ROQIKRX5AV4F23WTAVS5ANCNFSM6AAAAAASWCLFHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Exactly, that does not survive exposure to reality. |
|
The model didn't work out like I thought it would so this idea is probably dead, but a bunch of ways of saying about the same thing are making a mess of reciprocal suggestions. (https://arctos.database.museum/guid/MSB:Para:39269 seems to be the ONE probably-parasite with something other than a 'parasite of' relationship, for example.) Tabling anyway.... |
Is your feature request related to a problem? Please describe.
https://github.com/ArctosDB/code-table-work/issues/40 is a request for a new term which seems like it's probably precise enough to not be discoverable; the collection has been using some other almost-interchangeable term, how could a user possibly end up in the right place?
#1842 is almost the opposite situation, where refusing to be overly precise means we can't come up with a simple pair of terms in 5 years.
https://github.com/ArctosDB/arctos/issues?q=is%3Aissue+%22collected+with%22 is beginning to seem like Schrödinger's relationships - we simultaneously know, and have absolutely no idea, what
collected withmeans....Etc., etc., etc. I think perhaps we're somehow almost perfectly doing too much and not enough with one concept. I don't think we can possibly be consistent in that environment, and so I don't think anyone can usefully find our assertions.
Describe what you're trying to accomplish
Less clutter. More discoverability.
Describe the solution you'd like
2 parts:
Describe alternatives you've considered
Lots of work-->low-quality data
Additional context
This cannot happen until #4604 is fully functional, and probably should not happen until that has been proven a bit, but perhaps if we can commit to the idea this can at least guide and simplify some conversations while functionality is pending.
Priority
?
The text was updated successfully, but these errors were encountered: