W3C home > Mailing lists > Public > public-gld-wg@w3.org > November 2013

Re: Resolving DCAT/ADMS Versioning (was Re: Naive question on DCAT versioning)

From: Richard Cyganiak <richard@cyganiak.de>
Date: Fri, 1 Nov 2013 06:45:47 +0100
Message-Id: <3AE2109A-A1EE-4F42-B9C8-3414FBD8F5DF@cyganiak.de>
Cc: Antoine Isaac <aisaac@few.vu.nl>, Fadi Maali <fadi.maali@deri.org>, Chris Beer <chris@codex.net.au>, Ghislain Atemezing <auguste.atemezing@eurecom.fr>, Public GLD WG <public-gld-wg@w3.org>
To: Phil Archer <phila@w3.org>

> On 31 Oct 2013, at 12:31, Phil Archer <phila@w3.org> wrote:
> 
> In Section 4, Vocabulary Overview, the paragraph that begins "Notice that a dataset in DCAT is defined as... " is appended with:
> 
> "DCAT does not have a prescribed concept of versioning. It is up to the implementer whether a modification creates a new dataset or is simply a more recently modified version of the same dataset. A versioning mechanism is defined for ADMS, which is a profile of DCAT."

Works for me.

Richard




> 
> This, I hope, meets Antoine's basic point but does not, I hope, create a contradiction or restriction that properly belongs elsewhere if anywhere.
> 
> Phil.
> 
> 
>> On 31/10/2013 11:11, Antoine Isaac wrote:
>> I disapprove of the "arguably a terrible policy". But anyway that's not
>> my point.
>> 
>> My basic and important discomfort is that DC does not say anything about
>> the use of dcterms:modified for versions of datasets. I'm aware that
>> DCAT shouldn't say much, too. But it should at least tell that there's
>> no policy: versions are important, users of DCAT will seek on how to
>> represent it. And these users may think that DCAT recommends
>> dcterms:modified for version, if there's no clear hint that actually
>> DCAT does not recommend anything.
>> 
>> For me pointing to a specific pattern (without enforcing it) was a way
>> to tell it. I reckon it is not optimal. Something more direct would work
>> for me too:
>> "We remind you that DCAT has nothing to say about representing versions.
>> dcterms:modified may fit your needs, or it may not. Please wait for a
>> best practice to emerge, or try to make one yourself."
>> I'm just not sure whether the editors want to be as direct in the spec.
>> 
>> Antoine
>> 
>> 
>>>> On 30 Oct 2013, at 17:00, Antoine Isaac <aisaac@few.vu.nl> wrote:
>>>> Perhaps one can clarify by adding something like this for the note on
>>>> dcterms:modified:
>>>> 
>>>> "The use of this term implies that a change has been made to the
>>>> dataset. Note that in some situations (e.g., the ADMS profile of
>>>> DCAT) the use of this term will be prescribed by the approach to
>>>> versioning, which may go as far as requiring any dataset change to
>>>> lead to the creation of a new version of the dataset, identified by a
>>>> specific URI."
>>> 
>>> I think this is counterproductive. This paragraph says three things:
>>> 
>>> 1. Extensions and profiles may place additional constraints on the use
>>> of this property.
>>> 
>>> 2. ADMS is one profile that does this.
>>> 
>>> 3. Profiles may require that a new IRI is assigned every time a
>>> dataset is modified.
>>> 
>>> The first point is redundant. It is true for every property in DCAT,
>>> and already stated generically elsewhere.
>>> 
>>> The second point is in the wrong document and introduces a pointless
>>> circular reference. It's not the job of the base spec to call
>>> attention to what a particular profile does for a particular property.
>>> 
>>> The third point invites confusion because (a) the DCAT spec imposes no
>>> such requirement, (b) the DCAT spec shouldn't single out one
>>> particular policy among many possible policies, and (c) it's arguably
>>> a terrible policy.
>>> 
>>> ---
>>> 
>>> The definition of dcterms:modified in the Dublin Core spec is this:
>>> "Date on which the resource was changed." Can we please stick with
>>> that? DCAT doesn't take a stance on the question what constitutes a
>>> change. DCAT profiles may belabour that question as much as they like,
>>> but the place to do that is in the profile's own spec!
>>> 
>>> Best,
>>> Richard
>>> 
>>> 
>>> 
>>> 
>>>> 
>>>> Best,
>>>> 
>>>> Antoine
>>>> 
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> DCAT doesn't have a concept of versioning. It is left to the
>>>>> publisher to decide whether a modification to a dataset is
>>>>> considered a new version or not.
>>>>> Therefore, dct:modified can be used in case the publisher chooses
>>>>> not to support versions. dct:modified is also needed  in case the
>>>>> data is modified since it was created however the catalog only lists
>>>>> the latest version of the dataset.
>>>>> 
>>>>> I suggest we add only the first text suggested by Phil to Section 4
>>>>> (Vocabulary Overview):
>>>>> 
>>>>> "DCAT does not have a prescribed concept of versioning. It is up to
>>>>> the implementer whether a modification creates a new dataset or is
>>>>> simply a more recently modified version of the same dataset. A
>>>>> versioning mechanism is defined for ADMS which is a profile of DCAT."
>>>>> 
>>>>> Regards,
>>>>> Fadi
>>>>> --------------------------------------------------
>>>>> Fadi Maali
>>>>> PhD student @ Insight Galway (formerly DERI)
>>>>> Irish Research Council Embark Scholarship holder
>>>>> http://www.deri.ie/users/fadi-maali
>>>>> 
>>>>>> On 30 Oct 2013, at 15:46, Chris Beer <chris@codex.net.au> wrote:
>>>>>> 
>>>>>> All
>>>>>> 
>>>>>> Prehaps we need to define what we mean by version in order
>>>>>> sucessfully conclude the discussion? (My previous +1 stands in that
>>>>>> I feel the rewrite as proposed makes more sense than the original.)
>>>>>> 
>>>>>> Richard does raise a valid point - when does a change stop being an
>>>>>> "edit" a.k.a modification, and start being a new version. Is it
>>>>>> enough as Ghislain says to make any change at all a change event
>>>>>> and use prov to detail the change and extent?
>>>>>> 
>>>>>> (By the same token, a new version may not necessarily be a
>>>>>> modification in practice but only in the metadata - for instance a
>>>>>> document (or dataset) going from draft to final without
>>>>>> modification other than the doc review status which is metadata.)
>>>>>> 
>>>>>> Cheers
>>>>>> 
>>>>>> Chris Beer
>>>>>> Australia
>>>>>> 
>>>>>> Sent from my Sony Xperia™ smartphone
>>>>>> 
>>>>>> ---- Richard Cyganiak wrote ----
>>>>>> 
>>>>>>> Phil,
>>>>>>> 
>>>>>>> The two proposed amendments appear to contradict each other. The
>>>>>>> first one says that DCAT doesn't prescribe a particular notion of
>>>>>>> versioning. I agree. The second one says that the use of :modified
>>>>>>> indicates a change that was small enough not to require a new
>>>>>>> version. This implies that certain changes would require a new
>>>>>>> version of a dataset and hence would require something that DCAT
>>>>>>> cannot provide. I disagree with that, and it contradicts the
>>>>>>> earlier statement. It also seems to imply that a new version is
>>>>>>> not a modification, which I find bizarre.
>>>>>>> 
>>>>>>> Richard
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On 29 Oct 2013, at 18:54, Phil Archer <phila@w3.org> wrote:
>>>>>>>> 
>>>>>>>> Dear all,
>>>>>>>> 
>>>>>>>> There was an active discussion on 31st July this year prompted by
>>>>>>>> a question Antoine raised with me. It was not actually resolved
>>>>>>>> however and so I am trying to do that here. I've re-read through
>>>>>>>> the thread and believe that no substantive changes are necessary,
>>>>>>>> however, two editorial changes would be useful as follows.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> In Section 4, Vocabulary Overview, the paragraph that begins
>>>>>>>> "Notice that a dataset in DCAT is defined as... " should be
>>>>>>>> appended with:
>>>>>>>> 
>>>>>>>> "DCAT does not have a prescribed concept of versioning. It is up
>>>>>>>> to the implementer whether a modification creates a new dataset
>>>>>>>> or is simply a more recently modified version of the same
>>>>>>>> dataset. A versioning mechanism is defined for ADMS which is a
>>>>>>>> profile of DCAT."
>>>>>>>> 
>>>>>>>> I think the definition and usage note for dcat:Dataset is correct
>>>>>>>> as is, however, the usage note for dct:modified, which currently
>>>>>>>> reads "The value of this property indicates a change to the
>>>>>>>> actual dataset, not a change to the catalog record. An absent
>>>>>>>> value may indicate that the dataset has never changed after its
>>>>>>>> initial publication, or that the date of last modification is not
>>>>>>>> known, or that the dataset is continuously updated."
>>>>>>>> 
>>>>>>>> should be appended with:
>>>>>>>> 
>>>>>>>> "The use of this term implies that a change has been made but
>>>>>>>> that this is not sufficient to have created a new version of the
>>>>>>>> dataset. New versions of a dataset should be identified and
>>>>>>>> cataloged separately."
>>>>>>>> 
>>>>>>>> These changes, I hope, clarify that DCAT does not have a concept
>>>>>>>> of versioning, that ADMS does, and that whether a modification
>>>>>>>> does or does not create a new version is application-specific.
>>>>>>>> The essential semantics, however, are unchanged.
>>>>>>>> 
>>>>>>>> Thoughts?
>>>>>>>> 
>>>>>>>> Phil.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 31/07/2013 19:45, Ghislain Atemezing wrote:
>>>>>>>>> Dear Antoine,
>>>>>>>>> 
>>>>>>>>> Sorry if I missed your point in my previous mail...
>>>>>>>>>> @Ghislain: I'm not sure I understand your point: "as far as it
>>>>>>>>>> is reflected in the metadata, such as dct:modified" seems to
>>>>>>>>>> hint that you're just updating an existing instance of
>>>>>>>>>> dcat:Dataset. But my point is about when there is a *new
>>>>>>>>>> resource* of dcat:Dataset, as explained above.
>>>>>>>>>> http://www.w3.org/TR/vocab-dcat/#Class:_Dataset does not say
>>>>>>>>>> anything about whether such treatment is allowed or discouraged
>>>>>>>>>> in DCAT. And thus if ADMS is compliant with DCAT or not.
>>>>>>>>> 
>>>>>>>>> Now that I read the entire thread with Makx, I understand better
>>>>>>>>> your point. And I agree there is nothing at the moment in DCAT
>>>>>>>>> to handle that issue properly.
>>>>>>>>> I wonder if this issue of versioning affects only DCAT. Maybe
>>>>>>>>> one solution could be to help the user by clarifying it
>>>>>>>>> somewhere in the spec; or maybe handling it like in the ORG
>>>>>>>>> vocabulary [1] by creation
>>>>>>>>> a dcat:DataSetEvent by linking to PROV-O vocabulary (e.g: with
>>>>>>>>> prov:wasDerivedFrom property).
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> Ghislain
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> [1] http://www.w3.org/TR/vocab-org/#org:ChangeEvent
>>>>>>>>> [2] http://www.w3.org/TR/prov-o/#wasDerivedFrom
>>>>>>>> 
>>>>>>>> --
>>>>>>>> 
>>>>>>>> Phil Archer
>>>>>>>> W3C eGovernment
>>>>>>>> 
>>>>>>>> http://philarcher.org
>>>>>>>> +44 (0)7887 767755
>>>>>>>> @philarcher1
> 
> -- 
> 
> 
> Phil Archer
> W3C eGovernment
> http://www.w3.org/egov/
> 
> http://philarcher.org
> +44 (0)7887 767755
> @philarcher1
> 
Received on Friday, 1 November 2013 05:46:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:40 UTC