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

I replied to Linda on Friday I was making an inquiry on how to proceed
(publish this document) as I described in my other response. 

https://lists.w3.org/Archives/Public/public-sdwig/2019Dec/0023.html

I find Working Draft as the best representation currently available to
reflect 'evergreen' status while we wait for that new type of document
categorization to be finalized and adopted. I can even make it such
that update to the main branch on github automatically publish updates
to the Working Draft.

There is also discussion originating from W3C side about reopening the
Spatial Data on the Web Working Group which unlike the Interest Group
opens up the full range of types of documents that can be published
under the W3C recommendation track. There has been a shift in the
thinking that prompted the earlier closing of the working group.

On Sun, 2019-12-08 at 22:00 +0000, Cox, Simon (L&W, Clayton) wrote:
> 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> 
> Verzonden: dinsdag 19 november 2019 11:40
> Aan: public-sdwig@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>
> 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:
> The presentation within the document now starts with worked examples,
> and then moves on to the vocabulary description
> 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
> The SPARQL rules for finding the ultimate feature-of-interest and to
> copy-down properties from a collection to its members have been
> streamlined
> There are tests for all the SPARQL
> There are RDF representations of all the examples
> 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
> Team Leader – Environmental Information Infrastructure
> CSIRO Land and Water
>  
> E 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
>    Deliver: Gate 3, Normanby Road, Clayton, Vic 3168
> people.csiro.au/Simon-Cox
> orcid.org/0000-0002-3884-3420
> github.com/dr-shorthair
> Twitter @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
>  
-- 
Ted Guild <ted@w3.org>
W3C Automotive Lead
https://www.w3.org/auto