Processing use cases
GEOSS Common Record proposal
Review ISO core for completeness
Lieberman, Yuqi Bai, Hervé Caumont, Erin Robinson, Joan Maso, Steve
Josh: Action from last teleconference
to develop separate process / workflow use cases, one for development /
publication and one for discovery and usage. Greg Yetman
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 core
completeness and I found that:
2 mandatory core 19115 elements are missing
Metadata point of
Metadata date stamp
Several optional or conditional
19115 elements are missing:
(Coordinate) Reference system
Metadata standard name
Metadata standard version
resolution of the dataset
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,
temporal) could be the minimum.
Josh: Good to distinguish
returnable and queryable for quality, e.g.
data quality status
Returnable (5) ISO data quality
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
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.
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
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
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.
There are component -> service associations but not many-to-many.
need to look for the balance between supporting the e2e thread - find
data, find service, access data through that service, and proposing
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.
- proposal table development
Steve - check on consolidated
requirement link, propose access condition queryable - returnable
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