Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add terms for specialized data type classes #187

Open
wdduncan opened this issue Sep 20, 2021 · 1 comment
Open

Add terms for specialized data type classes #187

wdduncan opened this issue Sep 20, 2021 · 1 comment

Comments

@wdduncan
Copy link
Member

In the NMDC, we define classes to capture complex object types.
For example, the class quantity value allows us to capture both the numeric and units parts of measurement. For example, the depth a biosample can be represented using:

:biosample#1 :depth [a :quantity-value; :has-numeric-value 5; :has-unit meter] .

We also use a has raw value property to capture value in the original data source (e.g., 5 meter). Not sure if that property is appropriate for COB, though.

This very similar to @jamesaoverton proposal for directly linking information to entity, which I think went something like:

:james#1 :has-quality :height#1 .
:height#1 :has-quantity 180; :has-unit cm .

But adds one more level of indirection. E.g.:

:james#1 :has-quality :height#1 .
:height#1 :has-attribute-value :qv#1 .
:qv#1 :has-numeric-value 180; :has-unit cm .

Depending on the need, the has-attribute-value can take different attribute value classes in its range: text value, timestamp value, etc.

A possible advantage I see (right now) in doing this, is that allows you to more easily specify the domain the data properties (e.g., the domain of has-numeric-value is quantity value). Whereas the domain of the general has-quantity data property may have to allow for many different types.

Is this level of indirection worth the cost? Is it over-modeling? Is it simpler to define a measurement datum that is about the entity? E.g.:

:james#1 :has-quality :height#1 .
:measurement-value#1 :is-about :height#1; :has-numeric-value 180; :has-unit cm .
@ddooley
Copy link
Contributor

ddooley commented Oct 2, 2021

I do like the "measurement datum" which can have parts - value, unit, and optional aboutness. This fits well with modelling a system's different components from a cognitive or robotics perspective. One assembly line component can be for measuring diameters of things (outputing a measurement datum) but it doesn't know what entity it is measuring. Another more general component that knows what entities are on the assembly line can an add an 'is-about' reference to the measurement datum, etc. in an integrative fashion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants