Arctos: Relationship advice needed

[dustymc]

I would like some advice on how to map relationships, since I believe what I have is mostly incompatible with https://github.com/gbif/model-material/blob/master/schema.sql#L486

Arctos relationships are simply identifiers with a 'references' addition. This means these are of essentially three forms:

1. https://arctos.database.museum/guid/MSB:Para:480 is parasite of https://arctos.database.museum/guid/MSB:Host:152
2. https://arctos.database.museum/guid/MSB:Para:28915 is a parasite of http://n2t.net/ark:/65665/3777ecb64-7edc-4479-8486-a0b584092bd0
3. https://arctos.database.museum/guid/UTEP:HerpOS:1920 is a parent of Junior

The first form generally complies with the GUM model, but eg the parasite might be encumbered, not yet entered, etc., etc. - I'd still have to filter (and I'd muck that up and break things...).

The second form still involves two unambiguous data objects, but I can't key-reference one of them. (It should be in GBIF so perhaps you can, but that won't always be true.)

The third is a blind pointer. Maybe someone on the planet can 'resolve' Junior, but I can't. (Probably not this Junior, but turtles can be pretty determined....)

I'd really like to just share these data (partially on the hope that someone will see them and tell us who Junior is!). Can that somehow be accommodated?

@Jegelewicz

[tucotuco]

I would like some advice on how to map relationships, since I believe what I have is mostly incompatible with https://github.com/gbif/model-material/blob/master/schema.sql#L486

Arctos relationships are simply identifiers with a 'references' addition. This means these are of essentially three forms:

But they still do follow the pattern subject-predicate-object. The subjects are always compatible. The predicates can always be mapped (interpretation will be a community-wide issue, for which I like @dustymc 's idea of including references to the definitions of controlled vocabulary values). It's the objects that are more broad than GUM currently supports in EntityRelationship because of example 3.

1. https://arctos.database.museum/guid/MSB:Para:480 is parasite of https://arctos.database.museum/guid/MSB:Host:152
2. https://arctos.database.museum/guid/MSB:Para:28915 is a parasite of http://n2t.net/ark:/65665/3777ecb64-7edc-4479-8486-a0b584092bd0
3. https://arctos.database.museum/guid/UTEP:HerpOS:1920 is a parent of Junior

The first form generally complies with the GUM model, but eg the parasite might be encumbered, not yet entered, etc., etc. - I'd still have to filter (and I'd muck that up and break things...).

This is the case covered by populating subject_entity_id, entity_relationship, and object_entity_id. Why do encumbrance present a challenge here? I can't see how that would be a problem the relationship is the thing encumbered.

The second form still involves two unambiguous data objects, but I can't key-reference one of them. (It should be in GBIF so perhaps you can, but that won't always be true.)

This is the case covered by populating subject_entity_id, entity_relationship, and object_entity_iri.

The third is a blind pointer. Maybe someone on the planet can 'resolve' Junior, but I can't. (Probably not this Junior, but turtles can be pretty determined....)

This is the one we don't currently support as a relationship. It seems like a very useful extension that ought to be supported. I mean, it's not that much different from adding whatever identifier to the Identifier table. I think the support of this is a very nice target outcome. I would love to add it now, but it would cause trouble for those who have already done their mappings, so let's add it to the outcomes list.

I'd really like to just share these data (partially on the hope that someone will see them and tell us who Junior is!). Can that somehow be accommodated?

If we add a field for object_entity_literal (or some better name), that would cover all of your cases. You would still have to conditionally populate one of three object fields for each relationship, unless @timrobertson100 thinks that one string object_entity field could be accommodated and interpreted. I think it certainly could in a publishing model.

[dustymc]

Why do encumbrance present a challenge here?

A:1 exists and claims to have a relationship to B:1, which is encumbered (or doesn't exist for whatever reason). A:1 is included, the relationship (owned by A:1) is included, B:1 IS NOT included and so there's no key/entity (and potentially no reciprocal relationship, but whatever).

subject_entity_id, entity_relationship, and object_entity_iri.

AHA - perfect! (Or, 2 outta three ain't bad.) In next export.

one string object_entity field could be accommodated

That'd be cool for me. (And I think Arctos is coming around to the idea that identifiers are identifiers, and it's up to the user to figure out what can be done with them - some are clicky, some of those actually go somewhere, some can be 'resolved' by pasting the UUID into the right place, some are just "1" and oh well, etc. - all the complication mostly confuses users, rather than the intended better organization.)

[timrobertson100]

I've seen a data commit since this discussion, and have just updated the DB (sorry, have been out in meetings).
Please can you review and close any issues that can be? @tucotuco @dustymc

[Jegelewicz]

My kids have had success with Tinder....

Sorry, I held back the first time this showed up in my notifications.

[tucotuco]

I have gone through Arctos issues and maked closed all I can. Some others seem closable but I have asked for confirmation.

The takeaway message from this one is the need to be able to make relationships to objects that are essentially just string literals. This outcome has been noted. @MortenHofft @timrobertson100 Can this issue be closed?