Re: Comments on ID50

the point is that fine grained semantics around version change is
problematic.  BTW the example does not relate olddistribution to
newDistribution - there are not replacements - so poorly chosen labels. And
i think that you have indeed identified the correct interpretation of my
example - there has been a change in X - you now need to go to the version
mechanisms to compare to find out what that change was... This was just an
example however, not a concrete proposal for a solution.

Rob




On Tue, 5 Sep 2017 at 19:54 Makx Dekkers <mail@makxdekkers.com> wrote:

> Rob,
>
>
>
> The example seems to indicate that you make an assertion in the metadata
> for the Dataset about a change in metadata for the Distribution:
>
>
>
> 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"
>
>
>
> It seems to me that you are trying to say something like “in comparison to
> the metadata of my:oldDistribution, there is now a (new/modified?)
> rdfs:comment in the metadata for Distribution my:newDistribution”. However,
> in the RDF of the example, there is no way that you can explicitly say that
> the dcat:versionChangesOn applies to the metadata of newDistribution as
> compared to oldDistribution. That is even more complicated if you have more
> than two distributions, where different relationships may exist between
> different pairs.
>
>
>
> I think it would be clearer in such a case to make assertions in the
> metadata for the distributions, e.g.
>
>
>
> my:newDistribution a dcat:Distribution ;
>
>   dct:isVersionOf my:oldDistribution ;
>
>   dcat:versionChangesOn rdfs:comment ;
>
>   rdfs:comment "XML with DTDs soooo old school so I added JSON-LD" .
>
>
>
> But also, taking one step back: how realistic is the use case that would
> require such fine-grained information about changes? I am not questioning
> that “it would be nice to have” but I wonder (a) would metadata creators
> (whether human or software) put in the effort to create such detailed
> information – given that it is already hard to get even a minimum set of
> reliable metadata for lots of datasets – and (b) what would metadata
> reusers (again human or software) do with the information? Do we know of
> any existing tools that could create or consume information at this level
> of detail – or even tools that are known to be stuck in the absence of this
> kind of detail?
>
>
>
> And if there is really a need to expose fine-grained change, why not use
> PROV-O which would be the more general way to do this?
>
>
>
> Makx.
>
>
>
>
>
> *From:* Rob Atkinson [mailto:rob@metalinkage.com.au]
> *Sent:* 05 September 2017 03:56
> *To:* Jaroslav Pullmann <jaroslav.pullmann@fit.fraunhofer.de>;
> Peter.Winstanley@gov.scot; public-dxwg-wg@w3.org
> *Subject:* 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>
>
>
>