- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Fri, 1 Nov 2013 06:45:47 +0100
- To: Phil Archer <phila@w3.org>
- 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>
> 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