Actions should have a name

[smrgeoinfo]

Because actions are being used to represent activities like cruises, alvin dives, field expeditions, other data acquisition initiatives, they should have a name.

[horsburgh]

@smrgeoinfo - my comment from earlier about grouping things by "datasets" rather than trying to do everything via "actions" may be relevant here too.

[smrgeoinfo]

The idea that the representation of an activity like a cruise/project/field expedition is represented in the database as a dataset is not appealing to me. Seems like it would create confusion about what 'dataset' is supposed to meaning, making it harder to explain using the schema to people.

[dr-shorthair]

Tend to agree with Steve here. In prov terms, a project or cruise is an activity which generates a dataset which is an entity. In bfo terms it's occurrent vs. continuant. It's likely to be confusing in the future to conflate these or make one a proxy for the other.

[PleiadesAustralia]

I have been having this problem with regard to Sampling Actions. Currently I need to save the SampleNumber as an ActionAnnotation. This seems to be dangerous as the sample number is an essential quality control identifier.

[emiliom]

I also tend to agree with @smrgeoinfo's recommendation, specially when taking into account @dr-shorthair's observations about PROV. Cruises, expeditions and such are prominent concepts and parents to a lot of downstream results. Using Datasets to represent these things is awkward and frail, at least in part because as more results are generated from, say, samples collected by a cruise (often years after the cruise), the DatasetResults mapping would need to be updated. A parent action takes care of this cleanly. If adding an action name greatly facilitates this need, I'm all for it. It's a simple change, though one involving a very central schema entity.

During the development of my early and unfinished PRISM Cruises ODM2 use case, I represented cruises as both a sampling feature with a spatial representation, and the corresponding action that represented the execution of that cruise. The sampling feature instance enabled the storing of a code, name, and uri, while parent-child relationships on both sampling features and actions enabled hierarchical linkage to all "derived" actions and results. Such a tight samplingfeature-action linkage may not always be possible, and I can see that an action name would be helpful.

Regarding @PleiadesAustralia's comment:

Currently I need to save the SampleNumber as an ActionAnnotation. This seems to be dangerous as the sample number is an essential quality control identifier.

For that particular need, I would definitely point to the use of SamplingFeatures.SamplingFeatureCode (plus SamplingFeatures.SamplingFeatureName). That's exactly what SamplingFeatures.SamplingFeatureCode is for. You're dealing with samples, which in ODM2 lingo are "specimens", a prominent SamplingFeatures type.

[PleiadesAustralia]

If sampling features are samples how do you deal with calibration and lab quality control samples which have no geo positions?

…

Sent from my iPhone On 29 Jun 2018, at 3:36 am, Emilio Mayorga <notifications@github.com<mailto:notifications@github.com>> wrote: I also tend to agree with @smrgeoinfo<https://github.com/smrgeoinfo>'s recommendation, specially when taking into account @dr-shorthair<https://github.com/dr-shorthair>'s observations about PROV. Cruises, expeditions and such are prominent concepts and parents to a lot of downstream results. Using Datasets to represent these things is awkward and frail, at least in part because as more results are generated from, say, samples collected by a cruise (often years after the cruise), the DatasetResults mapping would need to be updated. A parent action takes care of this cleanly. If adding an action name greatly facilitates this need, I'm all for it. It's a simple change, though one involving a very central schema entity. During the development of my early and unfinished PRISM Cruises ODM2 use case<https://github.com/ODM2/ODM2/tree/master/usecases/prismxan>, I represented cruises as both a sampling feature with a spatial representation, and the corresponding action that represented the execution of that cruise. The sampling feature instance enabled the storing of a code, name, and uri, while parent-child relationships on both sampling features and actions enabled hierarchical linkage to all "derived" actions and results. Such a tight samplingfeature-action linkage may not always be possible, and I can see that an action name would be helpful. Regarding @PleiadesAustralia<https://github.com/PleiadesAustralia>'s comment: Currently I need to save the SampleNumber as an ActionAnnotation. This seems to be dangerous as the sample number is an essential quality control identifier. For that particular need, I would definitely point to the use of SamplingFeatures.SamplingFeatureCode (plus SamplingFeatures.SamplingFeatureName). That's exactly what SamplingFeatures.SamplingFeatureCode is for. You're dealing with samples, which in ODM2 lingo are "specimens", a prominent SamplingFeatures type. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#135 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AlE2g7JasB90JZ4HLjGQ61nsSI1N6TIcks5uBTBIgaJpZM4OEU2f>.

[emiliom]

Geospatial information in SamplingFeatures is not required. One of the reasons for this is precisely to support specimens like the ones you mention.

See the attributes of a Specimens entity., including the specimen type CV and the IsFieldSpecimen flag.

[PleiadesAustralia]

Thanks Emilo - I have begun to implement it that way.

…

Sent from my iPhone On 29 Jun 2018, at 11:40 pm, Emilio Mayorga <notifications@github.com<mailto:notifications@github.com>> wrote: Geospatial information in SamplingFeatures is not required. One of the reasons for this is precisely to support specimens like the ones you mention. See the attributes of a Specimens entity.<http://odm2.github.io/ODM2/schemas/ODM2_Current/tables/ODM2SamplingFeatures_Specimens.html>, including the specimen type CV<http://vocabulary.odm2.org/specimentype/> and the IsFieldSpecimen flag. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#135 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AlE2g2vNNCXSmR2HEXL9CsIdz6i8dnyUks5uBkp6gaJpZM4OEU2f>.

[aufdenkampe]

@PleiadesAustralia, I completely agree with @emiliom regarding his suggestions for how to store your sample numbers.

[PleiadesAustralia]

Thanks Anthony - I got the message and really like the design with sampling features and specimens once I got over turning my world around 180 degrees.

…

Sent from my iPhone On 9 Aug 2018, at 6:39 am, Anthony Aufdenkampe <notifications@github.com<mailto:notifications@github.com>> wrote: @PleiadesAustralia<https://github.com/PleiadesAustralia>, I completely agree with @emiliom<https://github.com/emiliom> regarding his suggestions for how to store your sample numbers. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#135 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AlE2g4w5clHUmtwFdwf53-W_DyJfdV9Kks5uO2iXgaJpZM4OEU2f>.

[aufdenkampe]

I really like the suggestion from @smrgeoinfo, and just implemented it in the ODM2.1_dev branch.

Here is the updated diagram reflecting f2bda09 and cumulative commits in the branch.

Note that I also moved ActionDescription up in the table, and I rearranged the ODM2Core diagram to align with the up-to-down & left-to-right cardinality conventions used in the ODM2OverviewSimplified diagram.