Re: Follow up on version-related requirements

Reading through this I get the impression that sometimes the term
version here refers to the version *designation* (e.g. "v1.2"
"20170809") or *type* and sometimes refers to the dataset, which is a
version. This is particularly true of the version identifier, which I
assume means that each version of a dataset must have its own
identifier, not that the version designation itself will have an
identifier. If that is the case, then we don't need "version identifier"
if each available dataset will have a dataset identifier as part of the
normal course of things.

If this isn't how people are seeing this, let's discuss.

kc



On 9/18/17 2:53 PM, Jaroslav Pullmann wrote:
> 
> 
>    Dear all, 
> 
>     today's call left many open questions regarding the "version" group of requirements. 
>    Even if their statement is still evolving I am convinced of their relevance, please find my remarks 
>    here to some of them:    
> 
>    Version subject [RVer1]
>    - the original UC restricts scope to Datasets, I think the DCAT group should explicitly decide which resources
>      will and in which extent (optional, mandatory) become subject of versioning. This decision should take into
>      account the consequences of creating resource versions at each of the levels (Catalog, Dataset, Distribution)
> 
>    Version definition [RVer2]
>    - it must be the DCAT core defining at least an abstract notion of change and versioning with regard to its resources, 
>     esp. identifying dimensions of resource, which changes should result in a new revision. It's particular implementation 
>     and rules might differ among profiles and be defined by those "locally", yet in compliance to DCAT's definition.  
>     While scenarios might help, versioning should not depend of them to remain a generally useful tool. 
> 
>    Version identifier [RVer3]
>    - of course, we need one. The question remains, how this version ID relates to URI of original/previous resource and further
>    properties of the version model (e.g. URI containing date or semantic version string)
> 
>    Version delta [RVer6]
>    - (in)formal semantics of the change underlying a new release, specified in terms of abstract definition (@DCAT) and 
>    detailed specification (@Profile), e.g. indicating the "type" of change (addition/removal/update of data etc.)
> 
>    Version discovery [RVer7]
>    - requires the versions to be discoverable and distinguishable, but would a client care? 
> 
>    But, I often come back to Makx' pragmatic question - how much versioning support do the DCAT publishers really need 
>    and how much do customers really understand (without becoming discouraged by that level of detail). Here the abstract 
>    definition from RVer2 should support the understanding of "meaningful" changes in lifecycle of DCAT resources. 
>    
>      Best regards
>    Jaroslav
> 
> 
> 

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234 (Signal)
skype: kcoylenet/+1-510-984-3600

Received on Wednesday, 20 September 2017 17:44:24 UTC