- From: Phil Archer <phila@w3.org>
- Date: Thu, 31 Oct 2013 11:31:42 +0000
- 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