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

On 11/1/13 6:45 AM, Richard Cyganiak wrote:
>
>> 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.

+1.
It doesn't address my issue with dcterms:modified. But if I'm the only one to see it then I won't raise it anymore.
And of course the whole discussion has lead to a really useful clarification on my *original* question, which I'm really happy about!

Best,

Antoine


>
>
>
>
>>
>> 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 08:32:52 UTC