RE: New editor's draft of SSN-Extensions available

Linda - thanks for picking this up. It definitely merits discussion.

There is more than one way of partitioning definitions in RDF vocabularies, and there is no unique consensus which to adopt.

For example - in OBO Foundry and in schema.org everything is in a single RDF namespace.
In the OBO case, a different mechanism is used (string patterns within the local identifier + separate graphs).
In schema.org keeping everything in one namespace is a deliberate tactic to reduce a barrier to adoption by people who are not as familiar with the principle of 'namespaces'.

W3C has leaned towards many namespaces with small numbers of elements in each one.
I can respect this, and I do think that having a discrete NS for the SSN vocabulary is helpful (though it is a shame that there are two ...).
However, this particular set of elements are aimed at a small set of extensions (one class, four properties) to the SOSA model, with the plan to normatively roll them into SSN in due course.
Since that is the target, and since we will be looking for implementation evidence when the time is right, it would be counterproductive to push the extensions out into yetanothernamespace - in particular that would likely create content out on the web whose URIs would not match the expected final ones.
Having a whole new namespace for just one class and four properties that p[primarily pick up some unfinished business from the original project is clumsy, unnecessary, and counter-productive IMO.

Simon


From: Linda van den Brink <l.vandenbrink@geonovum.nl>
Sent: Friday, 6 December, 2019 21:29
To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; public-sdwig@w3.org; ted@w3.org
Cc: Ilkka Rinne <ilkka.rinne@spatineo.com>; Kathi Schleidt <kathi@datacove.eu>; Stephen Richard (smrTucson@gmail.com) <smrTucson@gmail.com>; 'Douglas Fils (dfils@oceanleadership.org)' <dfils@oceanleadership.org>; Siddeswara Guru <s.guru@uq.edu.au>; Nick Car (nicholas.car@surroundaustralia.com) <nicholas.car@surroundaustralia.com>; Rob Atkinson <rob.atkinson@surroundaustralia.com>
Subject: RE: New editor's draft of SSN-Extensions available

Hi all,

With regard to moving the extensions into the SOSA namespace - this may well fit with the new proposal at W3C to support a new process for 'evergreen' standards, which are continually in development. However, I don't know if within the _current_ process it would be ok to add extensions to a namespace which is in use by a Recommendation.

Ted, do you have any guidance on this?

Other than that - are there any objections to moving the current SSN-extensions editors draft to WD? I see no issues raised on Github about this proposal, nor replies to this email.

Linda

Van: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>>
Verzonden: dinsdag 19 november 2019 11:40
Aan: public-sdwig@w3.org<mailto:public-sdwig@w3.org>
CC: Ilkka Rinne <ilkka.rinne@spatineo.com<mailto:ilkka.rinne@spatineo.com>>; Kathi Schleidt <kathi@datacove.eu<mailto:kathi@datacove.eu>>; Stephen Richard (smrTucson@gmail.com<mailto:smrTucson@gmail.com>) <smrTucson@gmail.com<mailto:smrTucson@gmail.com>>; 'Douglas Fils (dfils@oceanleadership.org<mailto:dfils@oceanleadership.org>)' <dfils@oceanleadership.org<mailto:dfils@oceanleadership.org>>; Siddeswara Guru <s.guru@uq.edu.au<mailto:s.guru@uq.edu.au>>; Nick Car (nicholas.car@surroundaustralia.com<mailto:nicholas.car@surroundaustralia.com>) <nicholas.car@surroundaustralia.com<mailto:nicholas.car@surroundaustralia.com>>; Rob Atkinson <rob.atkinson@surroundaustralia.com<mailto:rob.atkinson@surroundaustralia.com>>
Onderwerp: New editor's draft of SSN-Extensions available

Colleagues -

A new 'Editor's Draft' of the SSN-EXT ontology is available at https://w3c.github.io/sdw/proposals/ssn-extensions/
Compared with the last Public Working Draft https://www.w3.org/TR/vocab-ssn-ext/ there have been a substantial set of changes to the ontology and the document, the most important of which are:

  1.  The presentation within the document now starts with worked examples, and then moves on to the vocabulary description
  2.  Two additional 'convenience' properties :hasOriginalSample and :isUltimateSampleOf to help relate a sample to the resources earlier in the sample-prep chain, which are usually considered important for discovery and collation
  3.  The SPARQL rules for finding the ultimate feature-of-interest and to copy-down properties from a collection to its members have been streamlined
  4.  There are tests for all the SPARQL
  5.  There are RDF representations of all the examples
  6.  I am proposing that these extensions be moved into the SOSA namespace, rather than a new namespace

The last item might raise some eyebrows. This is a change from the PWD. My thinking here is that these extensions should be rolled into the base vocabulary in dues course, so it is better that they share the same namespace. I tested out the ssn-ext vocabulary with a user group (TERN) who are harmonizing ecology and biodiversity observations. It all worked very well, but yet again one thing that always confuses new adopters is too many namespaces! So anything we can do to relieve that is likely to help adoption. Remember - all schema.org elements - whether experimental, proposed or adopted, are in a single namespace. And as the SSN extensions are packaged in a separate RDF _graph_ (RDF file) no-one has to load them if they don't want to encounter them.

I have a little extra work to do on the document, primarily in the alignments section, but I think it is good enough for review now and I welcome comments. If you have comments which can be expressed as discrete issues, then please create a GitHub issue here: https://github.com/w3c/sdw/issues and tag it [ssn-ext]. Else kick off a conversation on this email list.

From a process point of view, I think the next step would be for this IG to agree to release it as a new Public Working Draft, replacing the previous one which was published a year ago and triggered some discussion, primarily in GitHub issues. The goal is to get the document published as a W3C Note / OGC Discussion Paper.

Thanks for your comments.

Simon

Simon J D Cox
Research Scientist - Environmental Informatics<https://research.csiro.au/ei>
Team Leader - Environmental Information Infrastructure
CSIRO Land and Water<http://www.csiro.au/Research/LWF>

E simon.cox@csiro.au<mailto:simon.cox@csiro.au> T +61 3 9545 2365 M +61 403 302 672
   Mail: Private Bag 10, Clayton South, Vic 3169
   Visit: Central Reception, Research Way, Clayton, Vic 3168  ///honey.zebra.chip<https://w3w.co/honey.zebra.chip>
   Deliver: Gate 3, Normanby Road, Clayton, Vic 3168
people.csiro.au/Simon-Cox<http://people.csiro.au/Simon-Cox>
orcid.org/0000-0002-3884-3420<http://orcid.org/0000-0002-3884-3420>
github.com/dr-shorthair<https://github.com/dr-shorthair>
Twitter @dr_shorthair<https://twitter.com/dr_shorthair>
https://xkcd.com/1810/
CSIRO acknowledges the Traditional Owners of the land, sea and waters, of the area that we live and work on across Australia. We acknowledge their continuing connection to their culture and we pay our respects to their Elders past and present.

The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.
CSIRO Australia's National Science Agency  |  csiro.au<https://www.csiro.au/>