Re: BP restructuring: Metadata section CRS

On 27/07/2016 7:58, Rob Atkinson wrote:
>
> In the presentation last night there was a reference to an ontology
> called "timeline"
>
> http://motools.sourceforge.net/timeline/timeline.html#overview
>
> IMHO this is an example of the _pattern_ we keep circling around - do we
> define an ontology that has different property terms for different
> aspects of metadata - timeline, CRS, UoM where we need processability as
> well as labelling, as well as comparison? (model, label, URI)
>
> Should we say "you should use a vocabulary that distinguishes the
> identifer, symbol, multi-lingual labels and allows models of metadata
> aspects" or "you should use a microformat in a literal string to allow
> multiple aspects of a given property value to be defined" ... or both,
> or either ...?
>
> Personally , I think we have a few critical ones that keep popping up -
> uom, CRS and precision - and activities to define Time, Spatial and
> Sensing - we should try to have a best practice from the wild - but that
> practice may mean providing an ontology under governance of _our
> community_ and recommending its use.
>
> noting that in general we almost never store results as "455.4 m/s" I
> would suggest that microformats are not prioritised, although if we
> allow values to be given datatypes we can let people use their favourite
> microformat.  I thus suggest that something like
>
> "BP is to provide a means to declare aspects of object properties,
> including the CRS of geometry, UoM and provision of a value, and
> potentially other metadata such as update.  Where such properties have a
> single value, and a single such property exists for an object it is
> possible to attach these declarations as additional properties to the
> containing object, or to a container object (such as a Dataset),
>
> Where this is ambiguous, due to multiple properties, then these aspects
> may be declared for container objects if the property they relate to is
> referenced.
>
> Where multiple values for a single property are present, and these do
> not share homegeneous aspects then two options exist:
> 1) reification - creation of a new object that defines the subject,
> object and predicate for each property, and additional aspects
> 2) binding values to specific datatypes ( 10.4^^qudt:Kelvin )
>
> note datatypes are URIs and can be compared or dereferenced as required,
> and this practice is compatible with the use of skos:notation as a BP
> for having "machine readable symbols"
>
> If we want to simplify this we need to make stronger prescriptive
> restrictions :-) I dont think you can make any of these patterns go away
> - they are all in use and have pros and cons. Recommending a specific
> vocabulary for each aspect. but allowing communities to make necessary
> alternative choices, and providing examples, and using that vocabulary
> consistently across different BP examples would go a long way IMHO.

+1!

Andrea

> Rob
>
> On Wed, 27 Jul 2016 at 13:02 Byron Cochrane <bcochrane@linz.govt.nz
> <mailto:bcochrane@linz.govt.nz>> wrote:
>
>     Hi,____
>
>     __ __
>
>     I would like to open more of a discussion about the CRS section
>     here.  It feels to me that it needs a great deal of work to be of
>     much use to the audience – at least how I envision the audience.  As
>     it stands, I think it is mostly uninformative at best.  It should at
>     least educate about web Mercator and WGS 84 and what the difference
>     is between them, should it not?____
>
>     __ __
>
>     My own perspective is that projections are a very useful tool in the
>     belt of a web developer / designer, but few really know that it is
>     available.  Some do, such as data journalists, Michael Corey and
>     Mike Bostock (of D3.js and topojson fame).   Here is a link to a map
>     projection guidance doc by Michael Corey that contains a great deal
>     of useful material on the subject -
>     https://source.opennews.org/en-US/learning/choosing-right-map-projection/.
>     While I am not suggesting that we go into as much detail as he does,
>     I think the approach, perhaps in a more abbreviated form is useful.
>     (As a side note, D3.js, the crème of data visualisation tools on the
>     web IMHO, has some projection support.)____
>
>     __ __
>
>     I would like for some to take a look at the above link and comment
>     on whether this approach is something we may want to adopt.  If so I
>     will offer to do at least a first cut.____
>
>     __ __
>
>     Cheers,____
>
>     Byron____
>
>     __ __
>
>     *From:*Linda van den Brink [mailto:l.vandenbrink@geonovum.nl
>     <mailto:l.vandenbrink@geonovum.nl>]
>     *Sent:* Wednesday, 27 July 2016 12:47 a.m.
>     *To:* SDW WG (public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>)
>     *Subject:* BP restructuring: Metadata section____
>
>     __ __
>
>     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____
>
>     __ __
>
>
>     ------------------------------------------------------------------------
>     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
>     <mailto: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.
>

-- 
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/

Received on Thursday, 28 July 2016 17:16:37 UTC