– DRAFT –
(MEETING TITLE)

<kcoyle> scribenick PWinstanley

kcoyle: first step to approve last week's minutes

Resolved: approved last week's minutes

<SimonCox> https://‌www.w3.org/‌2017/‌08/‌14-dxwg-minutes

kcoyle: brinef update from UCR group - impromtu meeting at the beginning of tada's mtg

roba: nothing further to add

Ixchel: nothing to add

<roba> we should schedule a UCR meeting later this week.

kcoyle: can you set a deadline for 1st draft?
… there is no hard dates between now and Nov1, but it would be good to have done weeks before because nov 9-10 there is the second F2F and we need to discuss requirements
… so it woul dbe good to have them in late stages of development so that they can be finalised then

roba: hope to get finalised by end next week

Jaroslav_Pullmann: it currenlty reads quite well. There may be need for additional work
… Peter mentioned KWIC index - might be useful

Jaroslav_Pullmann: Ididn't write down use cases that we didn't consider for continueation. Was there a resolution on how to proceed?

kcoyle: no - is there an out of scope tag?

Jaroslav_Pullmann: Thomas just closed them - that is just the input I wokred on

kcoyle: can we actually mark them as being out of scope, so that the decision is explicit?

kcoyle: I will send you a list

Jaroslav_Pullmann: I will add a new tag, update the wiki etc, and mark them as out of scope on the wiki (retained, but marked as out of scope)

kcoyle: yes, the document will be part of the archive

Jaroslav_Pullmann: How should I proceed wiht the requirements list - some (e.g. INSPIRE) have many requirements?

kcoyle: If the authors still think the requirements are relevant then they can add a slimmer use case

Jaroslav_Pullmann: What about requirements on the profile? They should be atomic
… should we attempt to have more complex and self-contained requirements?

kcoyle: essentially up to you/the group. As we discuss requirements we will see which style works best

SimonCox: With UCR doc, it is a collation from the wiki into the doc proper. The discussions in the meetings - is that implied by the UC being in the doc. I don't see anything about status

roba: if they have been marked out of scope by the dicussion then that is recorded
… the UCs are edited and curated to provide a testable set - there is no significance re: order. There is a lot of duplication and I have been editing and curating to simplify and dedupe. There is still some work to do

kcoyle: we are still considering new use cases

Jaroslav_Pullmann: I will have a version of UC by end of next week, as Rob mentioned, ready for discussion

kcoyle: any report on activity of the DCAT group?

SimonCox: Nothing to report. Holiday time, perhaps. My sense is that a lot of activity is predicated on the UCR doc being finalised

kcoyle: Open Action Items:

kcoyle: Peter, you have one?

PWinstanley: Done, but I have a clash in numbering that I will resolve today

kcoyle: we have 2 use cases -
… I introduced those on the mailing list - there has been some discussion

<kcoyle> https://‌www.w3.org/‌2017/‌dxwg/‌wiki/‌Use_Case_Working_Space#ID49

kcoyle: there is also UC 49

SimonCox: The UC comes from a meeting wiht a colleague, we realised that a lot of data discovery in the domains we work in uses project context as an angle for discovery
… generalising a little bit, there is perhaps a business context for this. We set out a use case and related to others, but putting it explicitly, we think a minimal decription of a project or business context is helpful

roba: my feeling is to accept 'as is'
… there is overlap with other requirements - the ability to connect with a deeper level of another model. We can't solve now, but it is consistent with other UCs
… The class for a project is a specific solution, but the description can help develop a more generlisable solution

<kcoyle> PROPOSED: accept UC 49 as in scope

<antoine> +1

<SimonCox> +1

+1

<roba> +1

<DaveBrowning> +1

<Ixchel> +1

<Makx> +1

Resolved: accept UC 49 as in scope

kcoyle: next is #47

<kcoyle> https://‌www.w3.org/‌2017/‌dxwg/‌wiki/‌Use_Case_Working_Space#ID47

roba: partly this appears to be provenance - there is also a quesiton about versions and additional metadata. There is also predicting the update cycle, which doesn't fit into both of the above

kcoyle: no, but that is an interesting question

roba: DCAT doesn't currently have a space for a rich model of this additional metadata on the type of update

DaveBrowning: I agere with the UC. The only issue, we have already touched on this, there is a complex interaction between versions and e.g. timepoints. Important for financial markets where there is no tight versioning and more a continuous stream of data
… some codificaiton compatible with DCAT wouldbe helpful. But we need to be cautious about inferences on e.g. version publication etc. I think the UC pushes discussion in the right direction

antoine: does the UC asks for a definition, or is it just a placeholder?

kcoyle: it doesn't determine . this can be done as DCAT 1.1 gets developed

antoine: do you have examples of methods ?

kcoyle: I only included one - the transaction file. In the mailing list discussion others (esp Makx) had a description of various types, so we will have to generate a list of types/methods

antoine: I anticipate an exhaustive list will be difficullt to generate, and this use case will only be easy to satisfy if we have a suitable link

<Makx> If we're taking this task on for DCAT 1.1, we need to be very clear what kinds of update mechanisms we need to model

kcoyle: if there is a list of methods then it will be easier - we don't want everyone mkaing up their own list. I don't know of a suitable existing vocab.

<Makx> Would we be looking at a 'generalised' update method inside datasets or would we limit it to particular types of data, e.g. bibliographic records?

kcoyle: we would be looking at a generalised method
… users must be able to discover the update method

<kcoyle> PROPOSED: accept ID 47 as in scope

<Makx> +1

<SimonCox> +1

<roba> +1

<DaveBrowning> +1

+1

<antoine> +1

<Ixchel> +1

Resolved: accept ID 47 as in scope

<kcoyle> https://‌www.w3.org/‌2017/‌dxwg/‌wiki/‌Use_Case_Working_Space#ID48

kcoyle: this is another complicated one that is about how the profile relates to validation - important because DC profiles developed >10y ago and they included all the information to inderstand the dataset - including the information now in SHACL/SHEX - a description of a metadata schema
… we are assuming that people will use a validaiton lang. How much of this should go into the profile (so that they are human friendly, but it also a validation language - how do we set the balance)

roba: I feel this UC reads more like a requirement than a UC. I agree with the proposition and hope that I've copied it right in the way I've pulled out the requirements for profiles

<Makx> DCAT-AP v1.1 is defined in a file that combines OWL and SHACL: e.g. https://‌github.com/‌SEMICeu/‌dcat-ap_shacl/‌blob/‌master/‌shacl-latest/‌dcat-ap.shapes.ttl

roba: generally speaking validation for artifacts will pull out some of the aspects, but perhaps not all of them (e.g. validating a response doesn't validate performance).
… if we get the generalised model of a profile right then that will work for this UC
… but it might be redundant

kcoyle: when do you mean by 'validate DCAT profiles'?

roba: if there is a specific validation required then there is no UC and so one needs to be written, but if not then it's not a UC in its current form. So, rewrite if there is a nuance that you think we are missing

kcoyle: are there other UCs that you think cover this?

<roba> 6.4 Create a way to retrieve more information about a profile. Create a way to retrieve more information about a profile. This must be flexible enough to support human and machine readable resources, such as input and editing guidance, validation resources, usage notes etc. 6.1 Definition of an application profile 6.3 Create a way to list the profiles implemented by a dataset or a specific distribution 5.2 Detailing and requesting additional constraints (profiles

roba: there are many UC basically about the same thing
… it may be an imperfect approach, but the intent is exactly what's required here - so please rewrite

kcoyle: I will rewrite - it is a matter of deciding how much the validation information can be carried in a profile, or whether that should be in a validation language

roba: working out the definition of a 'profile' wiill be helpful here. validation languages are 'meta' profiles
… when we start talking about negotiation by profile, we will then need to go into this more deeply

Action: on kcoyle - rewrite UC48

<trackbot> Error finding 'on'. You can review and register nicknames at <https://‌www.w3.org/‌2017/‌dxwg/‌track/‌users>.

Action: kcoyle to rewrite UC48

<trackbot> Created ACTION-34 - Rewrite uc48 [on Karen Coyle - due 2017-08-28].

roba: from a UC perspective, pre and post-conditions are helpful. Intended effect etc

bye

<Makx> Just added link to DCAT-AP OWL/SHACL tp ID48

<Makx> bye

<roba> bye all