I'm opening this PR for discussion only. Please do not merge yet!
It is intended as a discussion point for @SimonFlower at the Bergen meeting, as an example of a DDSS element with facilities.
The additions to this file are automatically created Facility definitions for each geomagnetic observatory, with related ContactPoint and Person definitions where they exist. Some fields are omitted if the don't exist dcat:contactPoint within a Facility, for example. Some fields are set to the value "None" if they don't exist, schema:postalCode "None"; within Person, for example. This was for programmatic simplicity for this first draft and these values can easily be changed, commented out or removed depending on what is needed.
There is currently no hierarchy of facilities, the only relationship each Facility has is with the Dataset defined in this file.
We have discussed whether INTERMAGNET itself should be a Facility but is this the right role for the whole entity? Could this be discussed confirmed at the meeting. But also here in INTERMAGNET we have Institutes which might be defined as facilities sitting between INTERMAGNET and the observatories.
In the current iteration there is no attempt to check whether the Person and ContactPoint elements have been defined elsewhere within this one file, within any WP13 file, or across the whole of EPOS. Also, the Person elements are defined with mailto IDs as that's what we have in our database, it might be that these individuals are known to have ORCID references. How much should we try to resolve elements down so that there is a single unique elemnt for each Person? What are the consequences of the same person, in real life, having two or more Person elements that differ slightly and have different IDs?
Although the file does not yet contain Instrument elements it looks like we should be able to expand this file to include some basic details of instruments for most facilities that are observatories.
Once there is some feedback from the Bergen meeting I will revise and expand this file so that it is acceptable for merging.
I'm opening this PR for discussion only. Please do not merge yet!
It is intended as a discussion point for @SimonFlower at the Bergen meeting, as an example of a DDSS element with facilities.
The additions to this file are automatically created
Facility
definitions for each geomagnetic observatory, with relatedContactPoint
andPerson
definitions where they exist. Some fields are omitted if the don't existdcat:contactPoint
within aFacility
, for example. Some fields are set to the value "None" if they don't exist,schema:postalCode "None";
withinPerson
, for example. This was for programmatic simplicity for this first draft and these values can easily be changed, commented out or removed depending on what is needed.There is currently no hierarchy of facilities, the only relationship each
Facility
has is with theDataset
defined in this file.We have discussed whether INTERMAGNET itself should be a
Facility
but is this the right role for the whole entity? Could this be discussed confirmed at the meeting. But also here in INTERMAGNET we have Institutes which might be defined as facilities sitting between INTERMAGNET and the observatories.In the current iteration there is no attempt to check whether the
Person
andContactPoint
elements have been defined elsewhere within this one file, within any WP13 file, or across the whole of EPOS. Also, thePerson
elements are defined withmailto
IDs as that's what we have in our database, it might be that these individuals are known to have ORCID references. How much should we try to resolve elements down so that there is a single unique elemnt for eachPerson
? What are the consequences of the same person, in real life, having two or morePerson
elements that differ slightly and have different IDs?Although the file does not yet contain
Instrument
elements it looks like we should be able to expand this file to include some basic details of instruments for most facilities that are observatories.Once there is some feedback from the Bergen meeting I will revise and expand this file so that it is acceptable for merging.