Re: Comments on ID50

I think fine-grained semantics of change is going to be very very hard to
nail down as a cross-community standard.

*** Warning - you are entering solution space without life-support ***

How about a simpler idea of recording the properties that change between
versions of a metadata record - i.e. if a distribution description has
changed, that tells you what you need to know.

dcat:versionChangesOn
 a rdfs:Property ;
rdfs:domain dcat:Dataset ;
rdfs:range rdfs:Property .

e.g.


my:dataset a dcat:Dataset ;
  dcat:Version "1.3.1" ;
  dcat:distribution my:oldDistribution ;
  rdfs:comment "love XML with DTDs as the only valid distribution" ;

becomes (without trying to solve co-existence of versions - assume its
somethign we can negotiate by graph or something)

my:dataset a dcat:Dataset ;
  dcat:Version "1.3.2" ;
  dcat:distribution my:oldDistribution ;
  dcat:distribution my:newDistribution ;
  dcat:versionChangesOn dcat:distribution, rdfs:comment;
   rdfs:comment "XML with DTDs soooo old school so I added JSON-LD"

Thus the semantics of the change partly comes from the property that is
recorded as changed (and this can be any property from any third party
specialised vocab.)   A way of having a version-change model attached as
well is just a special case of any fine grained semantics attached using
any specific 3rd party vocabulary.

Variations would be a set of more specific changes:

 dcat:versionAddPropertyValue , dcat:versionDeletePropertyValue ,
dcat:versionCorrectPropertyValue, dcat:versionUpdatePropertyValue

or by reifying and annotating each change:

dcat:versionChangesOn [ dcat:changedProperty dcat:distributiuon,
dcat:changeType dcat:Addition, rdfs:comment "updated to comply with DWBP
guidelines" ] .

 Big benefit - only have to worry about classifying changes to DCAT - not
all possible changes to datasets, yet still have a canonical means to
address them

Rob

On Tue, 5 Sep 2017 at 01:45 Jaroslav Pullmann <
jaroslav.pullmann@fit.fraunhofer.de> wrote:

>
>    Dear Peter, dear all
>
>      as said, the use case of distinguishing the type of
> Dataset/Distribution update makes sense to me,
>     e.g. when it comes to the decision whether to notify a its clients of
> "substantial" changes or not.
>     Within your  UC description there are samples of changes to content
> (deduplication) and Distribution
>     (compression), the latter not related to content, i.e. Dataset part.
>
>     Would you mind to generally consider "typology of change" applied to
> any DCAT resource (Catalog/Dataset/
>     Distribution), where the "change to information content" is one of the
> change types?
>
>     Each type has to be further specified with regards to affected
> dimensions (only), e.g. cutting down 5 past years
>     of data series affects the temporal coverage resulting in a new
> coverage range (but not influencing the semantics).
>
>    We might consider subclassing prov:Activity to model and define some
> generic types of change, examples
>    given by Prov-O document among others are: "processing",
> "transforming", "modifying", "relocating".
>    In case of  "altering" information content of Dataset we should define
> the conditions when this happens and
>    on the contrary which Dataset updates do not lead to a change of this
> category.
>
>     Best regards
>    Jaroslav
>
> --
> Jaroslav Pullmann
> Fraunhofer Institute for Applied Information Technology FIT
> User-Centered Ubiquitous Computing
> Schloss Birlinghoven | D-53757 Sankt Augustin | Germany
> Phone: +49-2241-143620 <+49%202241%20143620> | Fax: +49-2241-142146
> <+49%202241%20142146>
>
>
>
>