Re: Follow up on version-related requirements

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

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> 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 http://kcoyle.net
> m: 1-510-435-8234 (Signal)
> skype: kcoylenet/+1-510-984-3600 <+1%20510-984-3600>
>
>