<Stijn_Goedertier> present (on behalf of AIV, Thomas D'Haenens)
<Caroline_> https://www.w3.org/2017/08/21-dxwg-minutes
Resolved: approve previous minutes
<Caroline_> https://w3c.github.io/dxwg/ucr/
draft of UCR on github -
Ixchel: checking back on wiki to make sure all use cases copied over
Jaroslav_Pullmann: looking at referencing/inferencing issues -
… references between usecases and requirements
… done with a script from requirements to use cases
… added 'out of scope' tag
… will contact respec authors to clarify creation of dynamic links
Action: Jaroslav_Pullmann contact respec authors to clarify creation of dynamic links
<trackbot> Created ACTION-35 - Contact respec authors to clarify creation of dynamic links [on Jaroslav Pullmann - due 2017-09-04].
<Makx> presnet+ Makx
Ixchel: couldn't close the actions 5, 11, 12
… these are done and can be closed
Jaroslav_Pullmann: still working on ID25
kcoyle: closed action 34
kcoyle: we discussed on the mailing list and I rewrote it as a use case
… about creating a profile that includes the same information that may by a validation script and need to have that on the profile
<kcoyle> https://www.w3.org/2017/dxwg/wiki/Use_Case_Working_Space#ID48
the link is above
... not sure about the requirements yey
SimonCox: the problem statement
kcoyle: SHACL is a W3C standard
… I would be happy to not have it there
… we can remove that
SimonCox: I suggest to change to machine readable
kcoyle: I will modify it
SimonCox: I don't think it change the requirements
kcoyle: it does not change the requirements
annette_g: the first requirement listed "" my concern is that they maybe not get created in that order
… I think the requirement should be that the profile should be completed by itself
kcoyle: I like that because is the sense of the problem statement
… I will change this requirement
kcoyle: the profile defines the metadata and the validation would validate it on the profile
annette_g: I would put separate so you don't have to link them
… we can think about ways how relashionship could work better
kcoyle: so validating the profile structure itsefl?
annette_g: using the profile to validate any metadata
kcoyle: that was my dream!
… but I think it is more than what people would be willing to accept
annette_g: it could say if the metadata would match or not that profile
kcoyle: we can keep it that in mind
Jaroslav_Pullmann: we should be technology agnostic as it was said before and mention machine processing
… how the profile state any requirements of valid dataset when is no formula to express
kcoyle: I think this is the task of the profile doc
Jaroslav_Pullmann: this is type of definition of the valid criteria for profile
kcoyle: I think it is going to come up in the profile taks
… we don't know yet if it is possible
Jaroslav_Pullmann: I would like to ask LarsG if in his experience is that sort of formalization
LarsG: there is a difference between human and machine readable
… I agre with kcoyle that it is something defines what a profile is
Jaroslav_Pullmann: it could be introduced in the description of the use case
… the profile target is humans and not machines
<Makx> See https://joinup.ec.europa.eu/asset/dcat_application_profile/asset_release/dcat-ap-v11 for various formats of the DCAT-AP profile
Jaroslav_Pullmann: if remains as it is we will not be able to define a certain criteria
LarsG: this is getting conceptual
… the profile is abstract
… it can be a profile document that can be described to humans
<Makx> Text, RDF schema, SHACL source all with the same information
LarsG: we can figure out as we go along
Jaroslav_Pullmann: it could be ilustrative
kcoyle: as an example the DublinCore profile was implemented in XML partly because the most logical serialization at the time
… you can display to users very well in XML
annette_g:
the reaseon to have it in human readable is the same to have in machine readable
+1 to annette_g
<kcoyle> PROPOSED: approve use case 48 as in scope
<annette_g> +1
<SimonCox> +1
<Stijn_Goedertier> +1
+1
<LarsG> +1
<Caroline_> +1
<Jaroslav_Pullmann> +1
Resolved: approve use case 48 as in scope, with changes as discussed
<Makx> +1
<Caroline_> The profile must clarify any relationship between profiles and available validation documents or code
<Caroline_> https://w3c.github.io/dxwg/ucr/#RID5
<Caroline_> kcoyle:
<Caroline_> this is a group of background that seemed to be related to each other
<Caroline_> ... it seems that version is something that we agreed to be needed
<Caroline_> ... we need to give them a context while discussing it
<Caroline_> ... this is a statement to the editors to thinks what might be the best way to approach in agreing modifying the requirement
SimonCox: in 6.5, the what is meant by "version in this context"? is context a dataset instance? or is it more general?
Jaroslav_Pullmann: needs to be coordinated with definitions in data exchange working group documents
SimonCox: concern - hope we are not intending to impose a limited set of versioning styles; perhaps can describe a few common practices
… not appropriate to limit to any versioning rules
Jaroslav_Pullmann: context = related to this group;
… e.g. dataset not for distribution
Ixchel: agree that it needs clarification; taken directly from use case
… get clarification from group
Jaroslav_Pullmann: derive a requirement that refers to scope of versioning for dcat - what aspects will be versioned?
… will be specified in relation to entities of dcat model?
annette_g: when we talk about versioning there's a big challenge in terms of how much to define
… very domain-specific, and not likely to change
… so we shouldn't get into defining versions, but make an inclusive vocabulary that people can encode what they call a version
+1
<Makx> +1 to annette_g: find ways to describe not prescribe
kcoyle: look at less controversial version requirements
Jaroslav_Pullmann: 6.5 should be split into more concrete requirements
… what is there isn't actionable for dcat subgroup work
annette_g: do we assume that we should not conflict with other w3c recommendations?
<Caroline_> kcoyle:
<Caroline_> kcoyle: I think we are suppose to take other W3C recommendations into consideration
<Caroline_> ... if we have any requirements that they could fulfill
<Caroline_> also you said something important that we should check if there is no confliction with other standards
<Caroline_> ... about Jaroslav_Pullmann comments one of the things that happens on the life of the group is that people start off and then don't continue. So we can take over that work and go on updating it
Jaroslav_Pullmann: if can't reach authors, we'll take on the requirements
… requirements need to be made concrete for sub-groups
SimonCox: what we do does not have to be totally consistent with previous w3c work, but best that we not conflict
… re:potential conflicts with PROV, ... is there something?
annette_g: don't see conflicts, but PROV does address this, so we should look at it
… it might provide a framework for us
Jaroslav_Pullmann: not ready to vote, esp. on 6.5. look at PROV and VOID. action to editors to look at prov and void and align them with ours
Action: Jaroslav_Pullmann and editors look at PROV and VOID
<trackbot> Created ACTION-36 - And editors look at prov and void [on Jaroslav Pullmann - due 2017-09-04].
<Makx> thanks, bye bye
<LarsG> Thanks, bye!
<Caroline_> rssagent generate v2
<Caroline_> RRSAgent generate minutes v2
rrsagent generate minutes v2
Succeeded: s/shoud/should/
Succeeded: s/metadate/metadata
Succeeded: s/The profile must clarify any relationship between profiles and available validation documents or code /