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

Addresses cases where 'parentNetwork' value is not an RA acronym in station's DS response #158

Open
kknee opened this issue Dec 3, 2014 · 6 comments

Comments

@kknee
Copy link
Member

kknee commented Dec 3, 2014

comments from @cheryldmorse

"I’ve updated the code so that the ‘parentNetwork’ is not empty for the network’s DS response (failure #1) as long as the ‘institution’ attribute exists in the NetCDF file. But ncSOS will still fail this requirement because the ‘parentNetwork’ may be set to a value that is not a RA acronym. In the NetCDF files that Alex used for his test cases the ‘institution’ attribute was set to a value of ‘Weatherflow Inc.’ which means that the ‘parentNetwork’ was set to ‘WeatherFlow Inc.’ and ncSOS failed the test case. How should we proceed when the ‘institution’ attribute is missing or set to a value that is not a RA acronym?"

and from @abirger
"My thought is that we should minimize the changes for now so we could complete the Milestone 1.0 at last, even with some non-critical flaws. Therefore, I believe that it would be quite satisfactory for now, if ncSOS could use for the ‘parentNetwork’ a value from a netCDF ‘institution’ attribute, and ensure that the ‘parentNetwork’ field is not empty in case the attribute is missing.
We should definitely resume discussion about this and other issues later within Milestone 2.0 framework."

@kknee kknee added this to the 1.1 milestone Dec 3, 2014
@kknee kknee modified the milestones: Version 2.0, Version 1.1: TDS 4.5 Compatibility Dec 5, 2014
@kknee
Copy link
Member Author

kknee commented Sep 9, 2016

@abirger, @cheryldmorse and I are defining the next milestone. Do we need to revisit this issue? The crosswalk indicates that institution should be used to define parentNetwork. What happens in the institution is not an RA acronym?

@abirger
Copy link

abirger commented Sep 9, 2016

@kknee , @cheryldmorse , formally, ncSOS will fail the describeSensor:IOOS-SOS.DescribeSensor- ResponseContainsValidOperationsMetadataProperty.6, which follows the IOOS Convention requirement for parentNetwork, if the parentNetwork does not contain RA acronym and IOOS codeSpace.
On the other hand, the 'institution' attribute designates "the institution of the person or group that collected the data", which is not necessarily an RA. From the IOOS perspective, RAs better fit into 'publisher' category. However, since the 'institution' attribute had been chosen as a source for the parentNetwork from the very beginning, I just assumed that de-facto it always (or, at least overwhelmingly) refers to RA. Is that correct?

@cheryldmorse cheryldmorse modified the milestones: Version 1.5, Version 2.0 Jul 17, 2017
@cheryldmorse
Copy link
Contributor

@mwengren, @abirger - Any thoughts on how we should proceed with this issue?

@mwengren
Copy link

mwengren commented Jul 18, 2017

Here's my logic from trying to step through the documentation to answer this question...

It seems to me that from the SOS SensorML guidelines, we require SensorML responses to return the following <sml:classifier> elements:

  • parentNetwork (e.g. “NANOOS”)
  • platformType (e.g. “buoy”)
  • operatorSector (e.g. “academic”)
  • publisher (e.g. “NANOOS”)
  • sponsor (e.g. “ACE”)

Of these, the relevant classifiers to this issue are 'parentNetwork', 'publisher', and 'sponsor' as each of these are of the type 'organization' in the MMISW codespace http://mmisw.org/ont/ioos/organization.

From the IOOS vocabulary definitions:

  • parentNetwork is the 'Regional or domain-specific entity serving as data assembly center and/or data service publisher', whereas:

  • publisher is the 'Data set or service publisher. The publisher is the responsible party for publishing data on the web usually via a web service and has no implied relationship to the party responsible for operating the data generating asset (e.g. a buoy or a numerical model)' and:

  • sponsor is 'A person, group, or organization’s full or partial support of an IOOS activity, asset, model, or product.'

Aside: why do we not require an 'operator' classifier in the SensorML as well (see SensorML guidelines )? Instead, 'operator' is a required <sml:contact> element, mapped from the 'creator_name' netCDF attribute according to the netCDF/SOS crosswalk. It seems it also belongs as another classifier. Maybe it was overlooked? A separate issue beside the point of this a bit, just wanted to mention it.

Unless I misunderstand, each of the 'parentNetwork', 'publisher' and 'sponsor' is required to be one of the values of 'organization' as defined here: http://mmisw.org/ont/ioos/organization in order to pass the conformance tests. So 'sponsors' can only be among the valid organizations in this list? Seems a bit restrictive.

I see a few problems:

  1. the http://mmisw.org/ont/ioos/organization list is too restrictive because it limits both the parentNetwork and sponsor (sponsor being the bigger issue since expected values for that attribute might be more broad - there must be other sponsors of IOOS assets out there other than these organizations). If we expanded that list to include additional organizations, this would solve the issue here with the 'institution' value not being valid once mapped to the 'parentNetwork' classifier, correct?

  2. the definitions of 'institution' and 'creator_name' are a bit ambiguous in ACDD:

  • institution: 'The name of the institution principally responsible for originating this data.'
  • creator_name: 'The name of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.'

What is the difference??

Should something other than 'institution' be mapped to 'parentNetwork'? How about 'publisher_name', which currently maps to the <sml:classifier>@name='publisher')?

I'm sure this was debated before, but in my thinking 'parentNetwork' is probably more often going to be the data publisher than the 'institution responsible for originating' the data. It should really be a an IOOS-specific netCDF Profile attribute (eg 'parentNetwork') but I don't think changing the required attribution is a path we want to go down at this point probably.

cc: @dpsnowden @kbailey-noaa @emiliom

</end rant>

@abirger
Copy link

abirger commented Jul 18, 2017

@mwengren , it’s too late today to start digging but as far as I remember, the “required” elements are (1) the elements that are defined as “globally mandatory” ones by the relevant OGC schemata + (2) the “globally optional” elements that IOOS stockholders considered worthy of being “community mandatory” for IOOS. There is nothing sacral in the second part, just the stockholder’s ideas at the moment when the IOOS SOS v1.0 was discussed. We can review and modify the second part anytime as SMEs think fit.

@mwengren
Copy link

mwengren commented Aug 4, 2017

As a followup, I discovered today that ncISO has the following mappings in ISO:

netCDF attribute name ISO Element
@creator_name CI_ResponsibleParty (role='orginator | pointOfContact') > gmd:individualName
@creator_url CI_ResponsibleParty (role='orginator | pointOfContact') > gmd:URL
@creator_email CI_ResponsibleParty (role='orginator | pointOfContact') >gmd:electronicMailAddress
@institution CI_ResponsibleParty (role='orginator | pointOfContact') > gmd:organizationName

This means that in ncISO @creator_name is assumed to be a person, who by definition is assumed to belong to @institution.

This differs from our netCDF to SOS mappings table, where @institution maps to parentNetwork classifier, and the various @creator_ attributes map to the <sml:ContactList role='operator'> metadata element.

So we will always be inconsistent in our SensorML metadata and the ISO XML produced by ncISO for netCDF files that use ncSOS, unless either of these change.

If however operator and parentNetwork are synonymous and interchangeable, this wouldn't be an issue. We have different definitions for each though:

  • operator: Platform operator used as classifier or contact type; will often be the platform owner as well, but an owner role is not currently specified
  • parentNetwork: Regional or domain-specific entity serving as data assembly center and/or data service publisher

Another smaller problem is that all of the ISO metadata from THREDDS/ncISO in our Catalog has <gmd:individualName> element with RA names rather than people. Here's an example.

We may want to consider making use of the @creator_type attribute in ACDD (and also trying to get an update made for ncISO to account for it, which I don't believe it does currently).

creator_type Specifies type of creator with one of the following: 'person', 'group', 'institution', or 'position'. If this attribute is not specified, the creator is assumed to be a person.

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

No branches or pull requests

4 participants