Resolved: approved last weeks minutes (NOTUC)
No new attendees
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.
temporal coverage submitted by Andrea (who isn't here)
<SimonCox> Make sure to use 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: http://github.com/biocaddie/WG3-MetadataSpecifications
<SimonCox> https://www.w3.org/TR/owl-time/#time:hasEnd etc
<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 links
… 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
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 not
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 discussed
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 overview)
… prepares a graphical view of the UCs
… will share the URL
kcoyle: should we mark this UC as good, can we vote?
<phila> Modelling Temporal Coverage
kcoyle: question is: Is it a valid UC that reflects requirements?
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 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 SDW
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 things.
… 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 DCAT"?
… 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 common
… 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 needed
<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 first
<Makx> what is missing?
<roba_> agree with keeping it but rename it - its not modelling..
<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
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
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 repeatable
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' needs
… 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
<Present__Ixchel> it's ID27
alejandra: if we remove modelling, does that mean that we only talk about start and end dates?
<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
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
<SimonCox> good night
<kcoyle> Thanks Lars for scribing!!