Re: Namespace persistence etc

Thanks Phil! Very useful indeed.

IMHO, the new SSN will be under a new namespace, and, thus, we have the 
freedom to do the required changes without having to add tons of 
deprecated terms (which we would have to given the new modular design). 
Even more importantly, SSN was the result of an incubator group and is 
neither a standard or recommendation. While I believe that we should 
clearly align the new SDW-SSN work to the old work and document how to 
migrate, we should not let this slow down our current efforts to produce 
the best possible ontology as this one will actually become a standard.

Would you agree?

Best,
Krzysztof


On 07/12/2016 10:12 PM, Phil Archer wrote:
> @Scott - please chime in with any variance to this from an OGC 
> perspective.
>
> Dear all,
>
> I must begin by apologising for not being on the SSN call today/last 
> night. I could make up some convoluted reason but the truth is that I 
> forgot.
>
> I know one of the topics discussed was the issue around vocabulary 
> term persistence so I should set out a few things about that.
>
> The principle is, I think, straightforward: any change made to a 
> vocabulary shouldn't break existing implementations. Since we don't 
> know who has an implementation, we can't write to everyone and ask "if 
> we change this will your thing break?" Therefore we have to be cautious.
>
> That's what leads to W3C saying that vocabulary terms may not be 
> deleted or their semantics changed radically. But it only applies at 
> the namespace level. If you have a new namespace, you can do what you 
> like since nothing will break. *However* it's going to be really 
> confusing if some terms in the old and new namespaces are the same but 
> with radically different semantics. So my interpretation is:
>
> Same namespace:
> ===============
> No deletions.
> No changing or tightening or semantics (i.e. don't add a new domain or 
> range - make a sub class|property and put the new restrictions on that)
> Deprecation is OK.
> Loosening semantics is OK (so you *can* remove a domain or range 
> restriction since it is extremely unlikely that doing so will break 
> anyone's existing implementation).
> Adding new terms is fine.
> Clarifying existing definitions is OK.
> Adding new translations of labels is expressly encouraged.
>
> Different namespace
> ===================
> We can be a little more relaxed here. Recall that documents on w3.org 
> are persistent so the original documentation will always be there (at 
> the original URI or redirected from it).
>
> No need to replicate the whole of the old vocabulary, so no need to 
> include deprecated terms - they are deprecated by not being included 
> in the new namespace.
>
> Assuming the vocabulary has the same name then terms that appear in 
> both old and new should broadly be the same although semantics can 
> change a little. It's a matter of judgement.
>
> The case I keep in mind is Dublin Core/DC Terms. dc:creator took 
> either text or a URI as a value - which was confusing. dcterms:creator 
> should take a URI.
>
> Hope this helps clarify things.
>
> Phil.
>


-- 
Krzysztof Janowicz

Geography Department, University of California, Santa Barbara
4830 Ellison Hall, Santa Barbara, CA 93106-4060

Email: jano@geog.ucsb.edu
Webpage: http://geog.ucsb.edu/~jano/
Semantic Web Journal: http://www.semantic-web-journal.net

Received on Wednesday, 13 July 2016 05:34:21 UTC