-
Notifications
You must be signed in to change notification settings - Fork 4
Meeting Notes 12.03.2021
Participants:
- Casper Andersen
- Rickard Armiento
- Francesca Bleken
- Stuart Chalk
- Jesper Friis
- Saulius Grazulis
- James Hester
The main topic of discussion centered around the latest iteration of how to describe/ontologize the CIF dictionaries. See issue #16 to follow the progress.
These rather self-contained sentences were taken as part of quick sub-points that were made during the initial part of the meeting.
Attach attributes to data names. Most important is type.
Make CATEGORY
a property of a data item.
Something is missing between SPACE_GROUP_SYMOP
and the _space_group_symop_*
.
CATEGORY
can only be retrieved from the dictionary, not the CIF file itself.
Saulius auto-generated some ontology from the DDL dictionary.
Should CATEGORY
be taken as a super-class of its data items or part of defining what a data item is?
We want to keep a notion of the hierarchy of data keys/items, e.g., _space_group_symop_id
being a sub-class of a space_group_symop
category. We don’t want to have a single level of the hierarchy with all data keys/items under DATA_ITEM
, since we then lose some conceptual sub-sets of the data keys/items. But is this possible?
We’ve decided to add a super-set of the more specific data keys/items, e.g., the specific _space_group_symop_id isA subclass of _space_group_symop_
, which hasCategory exactly 1 SPACE_GROUP_SYMOP
and isA DATA_ITEM
, while SPACE_GROUP_SYMOP isA CATEGORY
and DATA_ITEM hasSpatialDirectPart CATEGORY
. This effectively splits CATEGORY
and DATA_ITEM
taxonomically/in the class hierarchy, while still defining the sub-sets of data keys/items.
Practically, split up the CIF ontology/-ies into a “basis” or “DDL” ontology that contains everything down to DATA_ITEM
and the individual _type
s. Then create “core” from the core CIF dictionary, e.g., SPACE_GROUP_SYMOP
, etc.