W3C home > Mailing lists > Public > public-sdw-wg@w3.org > September 2016

Re: Referencing UCR requirements in other documents: not by number

From: Rob Atkinson <rob@metalinkage.com.au>
Date: Tue, 27 Sep 2016 12:20:46 +0000
Message-ID: <CACfF9LwNtv9wgr-1c2N2bCPUnG00wK5OedzfWaV5fwo79Za1yw@mail.gmail.com>
To: Dmitry Brizhinev <dmitry.brizhinev@anu.edu.au>, Frans Knibbe <frans.knibbe@geodan.nl>
Cc: SDW WG Public List <public-sdw-wg@w3.org>
Why not generate a SKOS vocabulary of the UCR elements?  If you need a
namespace to serve it http://resources.opengeospatial.org/def/bp/{scheme}
would be great - as it would allow me to exploit an existing Linked Data
infrastructure to serve these in multiple formats.

We can do the same for the BP too - and link them (eating our own BP


On Tue, 27 Sep 2016 at 20:22 Dmitry Brizhinev <dmitry.brizhinev@anu.edu.au>

> Good point, I'll fix those soon.
> On 27 September 2016 at 20:17, Frans Knibbe <frans.knibbe@geodan.nl>
> wrote:
>> Hello,
>> A note for everyone (especially document editors) referencing
>> requirements from the Use Cases and Requirements document: When reading the
>> draft of the note Publishing and Using Earth Observation Data with the
>> RDF Data Cube and the Discrete Global Grid System
>> <http://w3c.github.io/sdw/eo-qb> I noticed that requirements in the UC&R
>> document are referred to by number, e.g. [Req 5.40
>> <https://www.w3.org/TR/sdw-ucr/#SpatialMetadata>]. I would like to point
>> out that fragment identifiers (e.g. #SpatialMetadata) can be considered
>> stable, but the numbering of the requirements is not. Section numbering is
>> handled by ReSpec and can change when requirements are added or removed. So
>> it is better to refer to them by their title, which should be short enough.
>> For example: Spatial metadata
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SpatialMetadata>
>> , spatial metadata requirement
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SpatialMetadata>
>> .
>> Regards,
>> Frans
Received on Tuesday, 27 September 2016 12:21:30 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:26 UTC