- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Thu, 31 Oct 2013 10:39:39 +0100
- To: Antoine Isaac <aisaac@few.vu.nl>
- Cc: Fadi Maali <fadi.maali@deri.org>, Chris Beer <chris@codex.net.au>, Phil Archer <phila@w3.org>, Ghislain Atemezing <auguste.atemezing@eurecom.fr>, Public GLD WG <public-gld-wg@w3.org>
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 >>>>> >>>> >> > >
Received on Thursday, 31 October 2013 09:40:05 UTC