What would you like to see added to HDMF?
The EntityKeyTable in HERD records that a key (user term) is associated with an entity (external resource), but it cannot express what kind of relationship that is. Today the implicit semantics are "the entity defines the term" (e.g., key "Homo sapiens" is defined by NCBI Taxonomy ID 9606). Other useful relationship types cannot be distinguished, for example:
sameAs / exact match (the term is identical to the entity)derivedFrom / source (the data was derived from the entity)relatedTo (a looser association)definedBy (the current implicit meaning)
Supporting typed relationships would make HERD more general and is one of the building blocks for the "foreign field" use case discussed in #327.
What solution would you like?
As suggested in #327 (comment), add a column to the EntityKeyTable that indicates the type of relationship between the entity and the key.
Proposed changes:
- Add a
relationship_type (name TBD) column to EntityKeyTable in hdmf.common.resources and to the HERD type in hdmf-common-schema. This requires a schema version bump and a decision on backward compatibility for existing HERD files (e.g., default the value to definedBy when reading files written with the previous schema).
- Extend
HERD.add_ref to accept an optional relationship type, with a sensible default preserving current behavior.
- Decide on the value space: a free-form string vs. a controlled vocabulary. Reusing an established vocabulary (e.g., SKOS mapping properties such as
skos:exactMatch / skos:relatedMatch, or schema.org/PROV terms) would maximize interoperability.
- Expose the relationship type in retrieval methods and dataframe output (
get_object_entities, to_dataframe).
Alternatives considered:
- Encoding the relationship in the
entity_uri or key name by convention. This is fragile and not queryable.
- A separate relationship table mapping
EntityKeyTable rows to relationship terms. More flexible (e.g., would allow multiple relationship types per entity-key pair) but heavier than needed for the known use cases.
Do you have any interest in helping implement the feature?
Yes.
Note
Split off from #327 (foreign fields), following the discussion in #327 (comment). Related: #1484.
What would you like to see added to HDMF?
The
EntityKeyTablein HERD records that a key (user term) is associated with an entity (external resource), but it cannot express what kind of relationship that is. Today the implicit semantics are "the entity defines the term" (e.g., key"Homo sapiens"is defined by NCBI Taxonomy ID 9606). Other useful relationship types cannot be distinguished, for example:sameAs/ exact match (the term is identical to the entity)derivedFrom/ source (the data was derived from the entity)relatedTo(a looser association)definedBy(the current implicit meaning)Supporting typed relationships would make HERD more general and is one of the building blocks for the "foreign field" use case discussed in #327.
What solution would you like?
As suggested in #327 (comment), add a column to the
EntityKeyTablethat indicates the type of relationship between the entity and the key.Proposed changes:
relationship_type(name TBD) column toEntityKeyTableinhdmf.common.resourcesand to theHERDtype in hdmf-common-schema. This requires a schema version bump and a decision on backward compatibility for existing HERD files (e.g., default the value todefinedBywhen reading files written with the previous schema).HERD.add_refto accept an optional relationship type, with a sensible default preserving current behavior.skos:exactMatch/skos:relatedMatch, or schema.org/PROV terms) would maximize interoperability.get_object_entities,to_dataframe).Alternatives considered:
entity_urior key name by convention. This is fragile and not queryable.EntityKeyTablerows to relationship terms. More flexible (e.g., would allow multiple relationship types per entity-key pair) but heavier than needed for the known use cases.Do you have any interest in helping implement the feature?
Yes.