GEOSS Common Record proposal table
Review ISO core for completeness
Data quality flags
Josh Lieberman, Yuqi Bai, Hervé Caumont, Erin Robinson, Joan Maso, Steve Browdy
Josh: Action to build a (best practice) proposal table for the GCR elements to recommend how to develop, publish, harvest, and query
Joan by email:
I spent sometime reviewing GEOSS Common Record for ISO 19115 coreJosh: Good to distinguish returnable and queryable for quality, e.g.
completeness and I found that:
Only 2 mandatory core 19115 elements are missing
Metadata point of contact
Metadata date stamp
Several optional or conditional 19115 elements are missing:
(Coordinate) Reference system
Data character set
Metadata standard name
Metadata standard version
Spatial resolution of the dataset
Metadata character set
Distribution format version
Also, I miss some reference to quality. To me, at least, some quality flag
or some sort is needed. One parameter for each dimension (positional,
thematic and temporal) could be the minimum.
Queryable data quality status
Returnable (5) ISO data quality elements
Josh: This is key for all ISO / GCR elements - to recommend both queryable and returnable properties
Josh: What about services: we recommend that everything be available at least through WMS, but what else is needed?
Steve: There should be enough 19119 elements in the service registration.
Erin: Not necessarily complete in terms, for example, of the coverage of a particular service on a particular dataset. The space-time footprint rather than just the bounding box.
Steve: similar problem to that of access conditions - each dataset can have a separate access condition in each (type of) service. Another set of 19115 elements on access conditions will be both queryable and returnable.
Josh: Good to distinguish 1-2 queryable access condition fields from other returnable fields
Steve: e.g. category of access and/or well-known license
Josh: we do keep getting down to metadata for "this data through this service". Are links enough for this, or is a single dataservice entity needed?
Yuqi: service registration in CSR is still a fallback for those who do not have a community catalog. Registration allows many choices for metadata documentation, though. How can we help the clearinghouse to be "smart" about mapping diverse metadata standards.
Erin: could the CSR have a practice of people registering GCR records when they register resources directly (as opposed to Community Catalogs)?
Steve: what be entered that is data-specific for a service registration?
Josh: practically, it's necessary to register a service multiple times, once for each dataset it exposes. Because the CSR doesn't really support associations.
Yuqi: There are component -> service associations but not many-to-many.
Josh: need to look for the balance between supporting the e2e thread - find data, find service, access data through that service, and proposing something achievable.
Yuqi: what is the next, simple step for supporting data - service associations more fully. Need a proposal for such a record.
Josh: action - propose an ISO AP extended dataservice record with links to the connected dataset and service instance, adding attributes such as data access elements.
Erin - proposal table development
Steve - check on consolidated requirement link, propose access condition queryable - returnable elements
Josh - dataservice entity proposal
All - review and improve the above.
Monday, July 26
Local time: http://timeanddate.com/worldclock/fixedtime.html?month=7&day=19&year=2010&hour=14&min=0&sec=0&p1=0
Dimdim & Telecon Info: http://my.dimdim.com/joshlieberman /
Telecon Access Code: 719290# # Telecon: Conference Dial-in Number: * USA (712) 432-1600 * Austria: 0820 4000 1552 * Belgium: 070 35 9974 * France: 0826 100 256 * Germany: 01805 00 76 09 * Ireland: 0818 270 021 * Italy: 848 390 156 * Netherlands: 0870 001 920 * Spain: 902 886025 * Switzerland: 0848 560 179 * UK: 0844 58 191 02