UC "Modelling temporal coverage" (was: [Minutes] 2017 06 26)

Dear colleagues,

I've been able to read the minutes only today, and I would like to contribute a few comments on the use case under discussion (which I submitted). Before that, my sincere apologies for not having been able to join the call.

1. I agree that the title ("Modeling temporal coverage") is too broad for the described use case, which deals only on how to specify a period with start/end dates. There are indeed different ways of specifying temporal coverage, as discussed during the call, that in many cases depend on the domain, and may be more or less fuzzy (as periods like the Middle Ages and geological eras). Actually, this issue has been one of the subjects of discussion in the SDW WG in relation to "time", and has brought requirements for the work on the OWL Time Ontology led by Simon. I have not included other scenarios in the use case just because I have no real-world examples at hand, whereas the start/end date issue is related to use cases widely implemented and which I'm familiar with. It makes sense to me that the existing alternatives are described in different use cases.

2. About the comment on the complexity of OWL Time, the point I was trying to make is not that it is not fit for specifying temporal coverage in general. Rather, the issue is that different ways of specifying temporal coverage (start/end date, periods, etc.) may require different ways of modelling it (e.g., a dct:Period + schema:startDate / schema:endDate, as in ADMS/DCAT-AP, or a more articulated representation, as done in OWL Time). I think that what would be beneficial for the community using DCAT is to provide harmonised patterns for the different use cases - not only to provide guidance, but also to facilitate interoperability.

3. What said in point (2) applies also to the use case related to "spatial" coverage [1]. There are different ways of specifying this information - the use case mentions 2 of them: geographical names, and geometries (spatial coordinates - as we may have temporal coordinates in temporal coverage). And we also have different levels of fuzziness. So, there's a relationship between the two that may be worth taking into account.

4. I see there was also a discussion on different "types" of dates, and Alejandra pointed to those supported by DataCite. On the mapping of DataCite to DCAT-AP we carried out a preliminary study at JRC, documented at [2]. As far as dates are concerned, the DataCite ones are basically those already defined in Dublin Core, with the only exception of "date collected". You can check the correspondences in the relevant mapping table, available at:




Andrea Perego, Ph.D.
Scientific / Technical Project Officer
European Commission DG JRC
Directorate B - Growth and Innovation
Unit B6 - Digital Economy
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy


The views expressed are purely those of the writer and may
not in any circumstances be regarded as stating an official
position of the European Commission.

From: Phil Archer [phila@w3.org]
Sent: 26 June 2017 17:15
To: public-dxwg-wg@w3.org
Subject: [Minutes] 2017 06 26

The minutes of today's minutes are at
https://www.w3.org/2017/06/26-dxwg-minutes with a snapshot below.

Thanks to Lars for scribing.

              Dataset Exchange Working Group Teleconference

26 June 2017

    [2]Agenda [3]IRC log

       [2] https://www.w3.org/2017/dxwg/wiki/Meetings:Telecon2017.06.26
       [3] http://www.w3.org/2017/06/26-dxwg-irc


           achille_zappa, alejandra, annette_g, Caroline_,
           Dave_Browning, Jaroslav_Pullmann, kcoyle, LarsG, Makx,
           mathieu, MJ_Han, nandana, phila, RiccardoAlbertoni, Rob
           Atkinson, SimonCox, Thomas

           Antoine, Colleen_Fallaw, Eric_Stephan, Luiz, Martin,
           Newton, Peter_Winstanley, Ruben

           Karen Coyle



      * [4]Meeting Minutes
          1. [5]Preliminaries
          2. [6]Approve last week's meeting minutes
          3. [7]new attendees?
          4. [8]Reports from sub-groups
          5. [9]Research Data
      * [10]Summary of Resolutions

Meeting Minutes

Approve last week's meeting minutes

    Resolved: approved last weeks minutes (NOTUC)

new attendees?

    No new attendees

Reports from sub-groups

    No reports from sub-groups

    kcoyle: wants to know if DCAT group has met

    alejandra: DCAT has exchanged a few emails but hasn't met yet.
     will keep us posted

    kcoyle: so far we have approved three use cases
     today we discuss are modelling temporal coverage,
     modelling spatial coverage
     and data access restrictions.

    <kcoyle> [11]https://www.w3.org/2017/dxwg/wiki/


    temporal coverage submitted by Andrea (who isn't here)

    <SimonCox> Make sure to use [12]https://www.w3.org/TR/owl-time/

      [12] https://www.w3.org/TR/owl-time/

    ... DCAT say to use dct:temporal

    ... SimonCox proposes owl-time

    <alejandra> Can we add to the links the following ones:

      [13] http://github.com/biocaddie/WG3-MetadataSpecifications

    <alejandra> and [14]https://developers.google.com/search/docs/

      [14] https://developers.google.com/search/docs/data-types/datasets

    <SimonCox> [15]https://www.w3.org/TR/owl-time/#time:hasEnd etc

      [15] https://www.w3.org/TR/owl-time/#time:hasEnd

    <alejandra> where also temporal coverage have been considered

    kcoyle: If people have more links, they can add that to the
    wiki page

    Makx: reacting to Andrea ADMS and DCAT-AP use schema:start and
    schema:end since owl-time looked too complicated
     many European data portals use that, too

    <roba_> * online for next 30 mins

    alejandra: Question about process: When I have comments or
     can I modify the UC directly in the Wiki or should it go
    through the UC editors?

    <mathieu> owl-time seems complicated but there can be more
    complex things to represent than just start and end dates

    <roba_> +1 to put to working use cases document.

    Present__Ixchel: If it's something that hasn't been discussed
    yet, just add it so that it's there for the meeting. Otherwise
    send an email to the editors

    <Jaroslav_Pullmann> thanks!

    Present__Ixchel: and they'll add it

    alejandra: Agrees with that process.

    kcoyle: From XXX there is a link to the working space

    kcoyle: there is no way to see which UCs we have discussed just
    by looking at the list

    Roba: plans to put a link to the consolidate use case
     status is more complicated
     some things may be solved, others not
     e. g. profile might be discussed but discovery of profiles

    kcoyle: You can split the UCs to have more atomic parts.
     important for people to see what is resolved

    <alejandra> I think that is good

    <alejandra> to add things to use cases that have not been

    Makx: has put something in alejandra's UC. Has marked with his
    name but wants to know if that's OK

    Present__Ixchel: Good idea.

    <alejandra> I agree on pinging the original author

    Present__Ixchel: If you want the orig author to look at it
    again, send a mail to the author
     and the list

    Jaroslav_Pullmann: Finds Makx's approach a good idea.
     People can use the comment section
     Status intended to be used as a progress indicator
     has started to create a mind map for the UC (has lost
     prepares a graphical view of the UCs
     will share the URL

    <kcoyle> ack

    kcoyle: should we mark this UC as good, can we vote?

    <phila> -> [16]https://www.w3.org/2017/dxwg/wiki/


    <phila> [17]Modelling Temporal Coverage


    <kcoyle> [18]https://www.w3.org/2017/dxwg/wiki/


    kcoyle: question is: Is it a valid UC that reflects

    annette_g: There are more complicated cases
     they should be expanded through discussion

    alejandra: Edge cases not so important

    SimonCox: Title is wrong. More about serialisation (how to
    serialise beginning and end)

    <roba_> modelling is covered by scope of [19]http://

      [19] http://w3c.github.io/sdw/qb4st/

    SimonCox: the description points out that in DCAT a URI is used
    to describe the time. That is considered cumbersome
     it's about the representation, not the content
     per se
     that is an old problem, when the issue is about modelling and
    when about syntax/representation

    kcoyle: Suggests to change the title

    roba_: It's neither syntax nor modelling, but more about a
    summary: DCAT proposes simplified view. Author might
     be simple, but provenance more deeply modelled
     spatio-temporal extent can be done through QB4ST as begun in

    Jaroslav_Pullmann: agrees. This is more about representation
    (date format) and might break down into simple properties
     part of an overall modelling context
     and that way put into a bigger relation

    Present__Ixchel: speaking from the user perspective. It's about
    understanding the different kind of temporal coverage. E. g.
    start and end of
     data acquisition. It's about bringing data together using
    their temporal contexts

    alejandra: Agrees. We also need to discuss the capabilities of
    DCAT. Obvious cases are dataset creation and modification. But
    also acceptance on DataCite.

    <phila> +1 to alejandra I was going to same something similar

    alejandra: We need a very flexible way to handle different
    kinds of dates

    Makx: Wonders if it's useful to change the scope of a UC. The
    UC builds on a real need and is a simple requirement.
     There are also a wider issue of modelling temporal aspects
     but not in this UC

    <Thomas> Agreed, Makx

    Jaroslav_Pullmann: relevance of the data is also important when
    searching for data in a catalogue.
     Some dates are fixed (distribution etc.).
     DCAT already has the catalogue record element for such
     Makx's focus is the temporal data itself, not of the dataset

    kcoyle: Do we need another UC?

    <SimonCox> types of dates - will it be a closed list?

    Jaroslav_Pullmann: Yes, maybe a meta-UC

    kcoyle: There is a problem putting too much into a single UC
     better to have simple specific UCs
     Who can do that?

    alejandra: DataCite has specific types of dates.
     that's an existing approach we can follow
     E. g. when the data was collected. That goes into processes

    <Makx> keep this one as it is, please

    roba_: This UC is about what we want to put into simple
    properties in DCAT. Should have a simple model.
     We probably don't need another UC for that
     but should have one simple UC (as a meta-UC) and one more
    deeply into modelling
     We can add another UC to the working space and map that to
    the existing

    <riccardoAlbertoni> +1 to kcoyle "adding further use cases on
    time issues" and keep this uc simple.

    Jaroslav_Pullmann: Would this be a UC like "temporal aspects in
     and then bring everything temporal into that

    kcoyle: we shouldn't be too abstract

    <Makx> +1 to keeping things practical

    kcoyle: when we look at UCs at a high level they have much in
     but we need to keep it practical

    Jaroslav_Pullmann: thought we could have one for all temporal
    dimensions in DCAT (API availability) all rooted in one meta-UC

    kcoyle: Jaroslav_Pullmann shouldn't hesitate to create one if

    <Makx> I vote for keeping it

    kcoyle: shall we edit the UC first or can we vote directly?

    <annette_g> +1 for keeping it but adding what's missing

    Jaroslav_Pullmann: agrees with Makx that we should edit the UC

    <Makx> what is missing?

    <roba_> agree with keeping it but rename it - its not

    <kcoyle> PROPOSE: accept ID29 and edit it to be specifically
    about start and end dates; and modify title to remove modeling

    SimonCox: does that mean start and end date of the data set
    (the record)?

    <Makx> this is the data itself

    <Makx> no this is not want the UC is about

    <roba_> record is overloaded term.. be careful

    Jaroslav_Pullmann: it's about the adding to the catalogue (the
    record) not the contents of the data set.

    <roba_> i think we are talking about the temporal coverage of
    the data - but we need to narrow down the semantics -
    observation time or phenomemon time

    SimonCox: the date of an observation is not always the same as
    what we are interested in (e. g. geological discovery vs.
    geological event)
     there are properties for that

    <kcoyle> acvk SimonCox

    <kcoyle> PROPOSED: accept ID29 and edit it to be specifically
    about start and end dates of the dataset; and modify title to
    remove modeling

    <alejandra> +1

    Makx: wants to clarify: it's about the year the (budget) data
    applies to, not about when the dataset was created

    Jaroslav_Pullmann: So it's about the temporal context of the
    data (phenomenon time), not about observation time

    SimonCox: Yes

    annette_g: Thought this would be more about deep thoughts about
    start and end dates. We shouldn't remove those from the UC or
    the discussion

    <Makx> disagree with extending use cases too much

    alejandra: the UC talks about start and end date. But when you
    work with time series you want intermediate points, too. That's
    also part of temporal coverage

    <Makx> intermittent periods is covered because dct:coverage is

    alejandra: similar things in other UCs

    kcoyle: we need more UCs on that topic

    SimonCox: we need to be more clear about specific requirements
    vs cross-domain reqs
     [other WG had 13 different kinds of dates]
     that was a very specialised application (weather forecasting)
     and there might be scientific cases in the future
     which leaves us with the dilemma that DCAT is
     general purpose which needs to be applicable in several
     domains but also needs to be applied to specific communities'
     We need to find the right balance

    Thomas: doesn't think we can capture all semantics in one
    simple model
     the dataset describer needs to use what works for them
     In specialist datasets there are dates that care for
    phenomenon time

    annette_g: we shouldn't try to make DCAT work for all
    scientific communities, but it should be easier to use if for
    the scientific community (uptake has been slow)

    <kcoyle> PROPOSED: accept ID27 and edit it to be specifically
    about start and end dates of the dataset; and modify title to
    remove modeling

    <Makx> +1

    <roba_> +1

    <SimonCox> +1

    <annette_g> +1

    <Caroline_> +1

    <Thomas> +1

    <mathieu> +1

    <Jaroslav_Pullmann> +1

    <achille_zappa> +1

    <riccardoAlbertoni> +1

    <phila> +1

    <Dave_Browning> +1

    <nandana> +1


    <Present__Ixchel> it's ID27

    <MJ_Han> +1

    <Present__Ixchel> +1

    alejandra: if we remove modelling, does that mean that we only
    talk about start and end dates?

    <alejandra> +1

    <roba_> Can we review UC1 to see if it covers general modelling
    of aspects, including time and suggest improvements please

    kcoyle: we can add modelling back again if necessary, but for
    now, yes

    <roba_> review offline

    <MJ_Han> In Requirements, spatial should be temporal.

    kcoyle: yes, roba_ , we can do that on the list or at the
    Oxford F2F

Research Data

    phila: Talked to WG chairs of RDA and then with people at
    CODATA (umbrella body for science unions)
     much potential interest in this WG but also in the general
     idea of research data as shared information on the web
     phila plans to continue with this
     RDA und CODATA watch this WG in order to make the web
     a large information space

    <annette_g> +1 exciting stuff!

    <SimonCox> As phila mentioned, I'm involved with RDA and CODATA
    so will keep links intact

    kcoyle: next week we'll discuss more UCs

    phila: If we discuss the outputs of this group in a subgroup,
    keep the mailing list in the loop to have it public

    <Caroline_> +1 to discuss in public :)

    <Caroline_> bye! thank you!

    <roba_> bye all

    <annette_g> bye!

    <riccardoAlbertoni> bye...

    <SimonCox> good night

    <Dave_Browning> bye

    <Present__Ixchel> bye

    <kcoyle> Thanks Lars for scribing!!

Summary of Resolutions

     1. [20]approved last weeks minutes (NOTUC)

Received on Saturday, 1 July 2017 00:11:20 UTC