Models for 'secondary' entities/types in the model

[mbrush]

If/how should we provide models for/constraints on secondary object types in the model, including Locations, Methods, Funding Mechanisms.

1) Representation of the location where a contribution was made

• Is this attribute necessary at all? if so, how to represent it? free text? a code of some kind (zip code, country code, city code, etc)? or proper Location object - e.g. see the FHIR Location resource here)?
• Or we could simply say this is out of scope and leave this up to implementers to determine how they want to represent this, and specify the model accordingly. This is what PROV seems to do . . . from https://www.w3.org/TR/prov-dm/#term-attribute-location:

  "A location can be an identifiable geographic place (ISO 19112), but it can also be a non-geographic place such as a directory, row, or column. As such, there are numerous ways in which location can be expressed, such as by a coordinate, address, landmark, and so forth. This document does not specify how to concretely express locations, but instead provide a mechanism to introduce locations, by means of a reserved attribute."

2) Representation of Plan/Method guiding a contribution to an artifact

• Same general options as for Location - free text, or provide a proper Method object with attributes. Or leave to implementer to define how they want to represent this?

[mbrush]

Based on decisions from 8-13 regarding detailed modeling of Agents being out of scope for our effort (see #2), it seems consistent to make similar recommendations for these secondary types. Specifically, we should provides extensible 'stub' types/classes for them that include the following attributes:

• id
• type
• label
• description
• externalID

Our documentation will recommend that specific implementations extend this minimal model based on their application requirements. If orthogonal efforts wish to develop a standard in this area (e.g. (ISO 19112 for locations), we can evaluate and decide if/how we want to recommend its use.

TO DO:

• [ ] add extensible stubs to the Information Model for Location, Method, and Funding Mechanism.

[diatomsRcool]

I would need to see a use case where "Location" is important. My initial inclination is that it isn't. Btw, I think location and method are more about provenance and less about attribution. Funding mechanism or Funder would be important for attribution. And this is where the automated connections of indirect contributions can come in handy.

[nicolevasilevsky]

I agree with @diatomsRcool that maybe location isn't needed