RE: SSN -- publishing dolce alignment separately

OGC has the concept of 'modularized' standards, with multiple conformance classes, which successively add more requirements. The implementer is then free to choose a conformance level. 

Seems to me that the SSN/DUL alignment issue would fit this model perfectly. It could all be in a single document, but the DUL alignment would be in a separate conformance class, which a user is free to use or not, as they choose. 
We just have to be careful to keep the groups of requirements in separate clauses, and label them separately so that implementers can accurately label their conformance level. 

Simon  

-----Original Message-----
From: Scott Simmons [mailto:ssimmons@opengeospatial.org] 
Sent: Wednesday, 20 April 2016 10:21 PM
To: Kerry Taylor <kerry.taylor@anu.edu.au>
Cc: Phil Archer <phila@w3.org>; Spatial Data on the Web Working Group <public-sdw-wg@w3.org>
Subject: Re: SSN -- publishing dolce alignment separately

Kerry,

Resending the content from my other response to you on this topic for the consumption of the WG.

"In OGC, a few options are possible. If the SSN work is to become an OGC standard, then DUL could be published as an extension (full weight of a standard, but optional component), a Best Practice, or a Discussion Paper. If SSN is to be a Best Practice, then it is most appropriate to make DUL a Discussion Paper.”

Best Regards,
Scott

> On Apr 20, 2016, at 3:54 AM, Kerry Taylor <kerry.taylor@anu.edu.au> wrote:
> 
>> Let me check I've understood you correctly. 
> Almost, but  certainly close enough for the answer to be what we are looking for. Thank you.
> 
> To correct, DUL is itself nothing to do with us. In the old "SSN" you could not use SSN without getting DUL into the bargain (via import and alignment axioms). Now we want to publish SSN minus DUL and minus alignment as the standard, but also separately publish the alignment ( probably still  importing DUL) as something weaker. 
> 
> That is (new) SSN as "Rec" and the (new, separated, as yet unnamed but in the namespace http://www.w3.org/ns/ssn/dul/) alignment ontology  as "Note inW3C parlance". 
> 
> Furthermore, I would be surprised if we did not want to pack other stuff into that Note as well (or separate Notes?) that correspond to other optional extras around SSN.
> 
> @Scott, how does this sit with you and OGC?
> --Kerry
> 
> 
> -----Original Message-----
> From: Phil Archer [mailto:phila@w3.org] 
> Sent: Wednesday, 20 April 2016 5:23 PM
> To: Kerry Taylor <kerry.taylor@anu.edu.au>; Scott Simmons <ssimmons@opengeospatial.org>
> Cc: Spatial Data on the Web Working Group <public-sdw-wg@w3.org>
> Subject: Re: SSN -- publishing dolce alignment separately
> 
> It depends (of course).
> 
> Let me check I've understood you correctly. SSN should be a standard, complete with implementation experience. DUL is an optional extension that you don't want to put through the full standardisation process but you need it to be published in a stable, persistent, citable form.
> 
> That would be a Rec and a Note in W3C parlance.
> 
> The W3C documents will almost certainly have short URIs of https://www.w3.org/TR/vocab-ssn/ https://www.w3.org/TR/vocab-dul/

> 
> And the namespace files are already in place of course at http://www.w3.org/ns/ssn/ http://www.w3.org/ns/ssn/dul/

> 
> HTH
> 
> Phil.
> 
> On 20/04/2016 01:19, Kerry Taylor wrote:
>> The SSN subgroup decided this morning that there are things (most particularly at this point, the DUL alignment) that we would like to publish *with* ssn but clearly not part of the "recommendation/standard".  Can you please advise us of the appropriate mechanism for this?
>> 
>> In particular with DUL, which was "built-in" to the orginal ssn we have disentangled it to make it "optional" and we prefer that part of (the previous) ssn does not carry the weight or obligations of a standard.
>> 
>> --Kerry
>> 
> 
> -- 
> 
> 
> Phil Archer
> W3C Data Activity Lead
> http://www.w3.org/2013/data/

> 
> http://philarcher.org

> +44 (0)7887 767755
> @philarcher1

Received on Wednesday, 27 April 2016 21:58:46 UTC