Re: BP restructuring: Metadata section

I dont think that "on-the-web" needs to make a statement about capture at
all - more about whether ISO19115 should be available for consumption. I
agree it should be - because federation using it is probably a BP.  To my
mind BP is actually the pattern that the same content is available in
existing standards as well as available using other formats for different
purposes - and I would include each of simplified mass-market consumption
cases, Linked Data navigation and semantic web reasoning oriented views as
different, but available as BP, that can and should co-exist.

Rob

On Wed, 27 Jul 2016 at 11:01 Byron Cochrane <bcochrane@linz.govt.nz> wrote:

> Hi Rob,
>
>
>
> I agree that capturing metadata in formats other than 19115 works fine,
> but I would be hesitant to call that best practice.
>
> This is a best practices document.  Can’t we say capture in 19115 is
> current best practice for spatial metadata capture?  Doing so does not
> preclude other approaches – especially compatible ones.
>
>
>
> Cheers,
>
> Byron
>
>
>
> *From:* Rob Atkinson [mailto:rob@metalinkage.com.au]
> *Sent:* Wednesday, 27 July 2016 11:41 a.m.
> *To:* Byron Cochrane; Andrea Perego; Linda van den Brink; SDW WG (
> public-sdw-wg@w3.org)
>
>
> *Subject:* Re: BP restructuring: Metadata section
>
>
>
> Hi Byron...
>
>
>
> another way of looking at this is that different metadata has different
> degrees of expressivity - and the form closest to the actual creation
> processes of the data is usually the most detailed and accurate.
>
>
>
> The implication is that ISO19115 is potentially a view of richer metadata
> itself - and/or a way of annotating it.  DCAT and RDf in general make
> attaching more detail relatively easy, and annotation of any component
> comes as a natural component.
>
>
>
> So I'm not sure that a BP should be as prescriptive as "data creators and
> publishers capture metadata in ISO 19115" - rather that they capture
> metadata in a form that can be used to generate both ISO 19115 XML  and
> GeoDCAT RDF resources.  Capturing in ISO19115 works - but its not the only
> way.
>
>
>
> Rob
>
>
>
>
>
>
>
> On Wed, 27 Jul 2016 at 07:05 Byron Cochrane <bcochrane@linz.govt.nz>
> wrote:
>
> Hi,
>
> Jumping in here with  questions and comments about the role of 19115 in
> this.
>
> Currently, the practice I am proposing here in NZ is that data creators
> and publishers capture metadata in ISO 19115 and publish GeoDCAT.  While
> GeoDCAT is great for search and discovery (two different things), it is
> only a subset of the 19115 standard.  For a more complete documentation of
> the dataset, ISO 19115 is still necessary.  But since 19115 is not (yet)
> linked data friendly, presentation in DCAT is a good best practice for
> publishing.
>
> So I would suggest that the full best practice would be to capture
> metadata in ISO 19115 and present as GeoDCAT on the web.  This is the way
> that current GeoDCAT tools that I know of are designed to work.
>
> Two further notions to throw out here, but not too sure how they fit.
> Good metadata is first and foremost a tool that is necessary for good data
> management.  Search and discovery is secondary to this.  Also, I like to
> think of metadata, presented as HTML, as the natural landing page for
> datasets.  Not sure yet if the default landing page should be GeoDCAT or
> 19115.
>
> Cheers,
> Byron
>
> -----Original Message-----
> From: Andrea Perego [mailto:andrea.perego@jrc.ec.europa.eu]
> Sent: Wednesday, 27 July 2016 2:55 a.m.
> To: Linda van den Brink; SDW WG (public-sdw-wg@w3.org)
> Subject: Re: BP restructuring: Metadata section
>
> Thanks, Linda.
>
> I would be happy to help here, also with examples.
>
> Some preliminary comments on the listed types of spatial metadata:
>
>  > data type (raster or vector)
>
> Not sure if this completely matches with the ISO 19115 notion of "spatial
> representation type" - which is modelled with a code list including "grid",
> "vector", "text table", etc. - see:
>
>
> https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#MD_SpatialRepresentationTypeCode
>
> In any case, GeoDCAT-AP models this information by using
> adms:representationTechnique + URIs corresponding to the items in the ISO
> 19115 code list.
>
>  > Coordinate Reference System(s)
>
> I've already mentioned the approach used in GeoDCAT-AP:
>
> https://lists.w3.org/Archives/Public/public-sdw-wg/2016May/0072.html
>
> The "link" between data and the relevant CRS(s) is made with
> dct:conformsTo - which is also in line with the use of such property in DQV
> to express conformance with a "standard".
>
>  > spatial resolution
>
> As I said in another mail [1], DQV may offer a solution to this:
>
> https://www.w3.org/TR/vocab-dqv/#ExpressDatasetAccuracyPrecision
>
> The examples cover spatial resolution expressed as horizontal ground
> distance, equivalent scale, angular distance (which is how spatial
> resolution is expressed in ISO 19115 - we just miss an example on vertical
> distance).
>
>
> About making "spatial *meta*data indexable", is this going under BP1 as
> well? I think we have already good examples to include, also showing how
> this is a feature that can be (more or less) easily integrated in existing
> geo catalogue services and tools.
>
> On this specific topic, I take the opportunity to mention that we started
> a mapping exercise between DCAT-AP + GeoDCAT-AP and Schema.org:
>
>
> https://webgate.ec.europa.eu/CITnet/stash/projects/ODCKAN/repos/dcat-ap-to-schema.org/
>
> One of the preliminary results of this work is: do we really need to map
> everything? Besides the fact that Schema.org does not include terms to
> model all what is in DCAT-AP / GeoDCAT-AP, the use cases addressed by these
> metadata schemas are different. So, the question is: what is really needed
> to be mapped to Schema.org to enable Web indexing and discoverability?
>
> I think this is a general design issue about enabling the re-use of
> spatial data (not only metadata), that, in my understanding, was shown
> pretty clearly in the Geonovum testbed, where only a "simplified"
> version of spatial data and metadata is represented via Schema.org.
>
> Cheers,
>
> Andrea
>
> ----
> [1]https://lists.w3.org/Archives/Public/public-sdw-wg/2016Jul/0164.html
>
>
> On 26/07/2016 14:47, Linda van den Brink wrote:
> > Hi all,
> >
> >
> >
> > Finally, some progress. I’ve begun restructuring the Best Practices
> > document based on the structure of the DWBP (same grouping and
> > ordering of BPs). I shuffled all the BPs around to the best of my
> > ability based on discussions we had in various places. I may have
> > missed some insights because I find it difficult to keep track of all
> > the mailing list discussions sometimes, so comments are more than
> > welcome.  I’ve not started merging/consolidating BPs yet, but will do
> > if appropriate. I’m working on them one by one, now.
> >
> >
> >
> > http://w3c.github.io/sdw/bp/
> >
> >
> >
> > In particular, I welcome more detailed comments on the section in the
> > BP on spatial metadata. http://w3c.github.io/sdw/bp/#bp-metadata
> >
> >
> >
> > I’ve got three BPs in that section at the moment.
> >
> >
> >
> > The first one is about spatial coverage and other spatial descriptive
> > metadata. Getting there, but needs examples at least.
> >
> >
> >
> > The second is about CRS – there have been comments on this in the past
> > as well as recent discussion, which I’ve tried to capture without
> > making the section overly long or complex. Please review!
> >
> >
> >
> > The third is on making the entities within a spatial dataset indexable
> > (it was SDWBP25 in the FPWD). Even though this is not really a spatial
> > but a general issue I’ve retained it for now, because it’s useful
> > information and not detailed in DWBP. And even though it’s not clearly
> > about metadata (at least not on dataset level), this section seems the
> > best fit for it. Also, this BP needs examples and can probably be
> improved.
> >
> >
> >
> > Your thoughts are appreciated!
> >
> >
> >
> > Linda
> >
> >
> >
>
> --
> Andrea Perego, Ph.D.
> Scientific / Technical Project Officer
> European Commission DG JRC
> Directorate B - Growth and Innovation
> Unit B6 - Digital Economy
> Via E. Fermi, 2749 - TP 262
> 21027 Ispra VA, Italy
>
> https://ec.europa.eu/jrc/
>
>
> This message contains information, which may be in confidence and may be
> subject to legal privilege. If you are not the intended recipient, you must
> not peruse, use, disseminate, distribute or copy this message. If you have
> received this message in error, please notify us immediately (Phone 0800
> 665 463 or info@linz.govt.nz) and destroy the original message. LINZ
> accepts no responsibility for changes to this email, or for any
> attachments, after its transmission from LINZ. Thank You.
>
>