Re: Follow up on version-related requirements

On 9/20/17 1:06 PM, Rob Atkinson wrote:
> IMHO There is definitely a need to handle versions of multiple things:
> 1) The DCAT "record" itself - whether this is handled by non-opaque
> identifiers of properties is a solution issue
> 2) The version of the dataset being described
> 3) The version of the profile the DCAT record conforms to

Do you think these are covered sufficiently in the requirements? I like
this enumeration of the elements, and it would be good to keep these in
mind.

kc

> 
> As all these potentially involve a common URI based identification
> approach, they should for simplicity also have a common approach to
> versions.  Dataset identification may however be indirect via DCAT
> records (i.e. potentially use multiple URI and  non-URI identification
> schemes) - so it all needs to be carefully laid out and described.
> 
> Rob
> 
> On Thu, 21 Sep 2017 at 03:43 Karen Coyle <kcoyle@kcoyle.net
> <mailto:kcoyle@kcoyle.net>> wrote:
> 
>     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 <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>     m: 1-510-435-8234 (Signal)
>     skype: kcoylenet/+1-510-984-3600 <tel:+1%20510-984-3600>
> 

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

Received on Thursday, 21 September 2017 00:32:49 UTC