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

I think Phil's most recent wording is fine. In the interest of
long-term durability, wondering if the reference to ADMS could be
something like "is defined (for example) for ADMS, which is..." my
point being that other DCAT profiles might emerge in the future.

On Thu, Oct 31, 2013 at 7:31 AM, Phil Archer <phila@w3.org> wrote:
> 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
>



-- 
John S. Erickson, Ph.D.
Director, Web Science Operations
Tetherless World Constellation (RPI)
<http://tw.rpi.edu> <olyerickson@gmail.com>
Twitter & Skype: olyerickson

Received on Thursday, 31 October 2013 11:35:31 UTC