Re: BP restructuring: Metadata section CRS

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.

Rob

On Wed, 27 Jul 2016 at 13:02 Byron Cochrane <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]
> *Sent:* Wednesday, 27 July 2016 12:47 a.m.
> *To:* SDW WG (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) 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.
>