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

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

From: Phil Archer <phila@w3.org>
Date: Thu, 31 Oct 2013 11:31:42 +0000
Message-ID: <52723F9E.1040504@w3.org>
To: Antoine Isaac <aisaac@few.vu.nl>, Richard Cyganiak <richard@cyganiak.de>
CC: 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>
Reading through the thread it seems there is universal disapproval of my 
second sentence but general agreement with the first. Therefore may I 
propose that the editors implement the first change only, namely:

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."

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 Thursday, 31 October 2013 11:32:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:52:09 UTC