- From: Rob Atkinson <rob@metalinkage.com.au>
- Date: Wed, 27 Jul 2016 05:58:12 +0000
- To: Byron Cochrane <bcochrane@linz.govt.nz>, Linda van den Brink <l.vandenbrink@geonovum.nl>, "SDW WG (public-sdw-wg@w3.org)" <public-sdw-wg@w3.org>
- Message-ID: <CACfF9LzQqKcx8wqN4bbP9Tg4eyb38F3ACeMOOyvbrYzKBHPQiQ@mail.gmail.com>
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. >
Received on Wednesday, 27 July 2016 05:58:56 UTC