Resolved: accept minutes of 06/12
Profiles may be written in or may link to a validation language (ShEx, SHACL, XMLschema). ID41 (5.41)
Profiles may be coordinated with validation schemas. ID48 (5.48)
<ncar> An obvious pair of in scope I think
<roba> +1 in scope - what does coordinated mean?
<roba> reference?
alejandra: what does related to/ ? mean
<roba> include?
<alejandra> +1 to changing the wording
<alejandra> associated?
kcoyle: may point to a validation schema -- could use a different form of words. Associated, etc
alejandra: I can't see the difference between the two.
kcoyle: there may be a link, but it might be server information (eg with conneg)
annette_g: giving a human readable description might be put here - not necessarily machine-redable
<alejandra> ok, the mention of validation language vs validation schema is implying two different associations
Jaroslav_Pullmann: what are we going to express with linking schema to profiles - a hint on where to find a schema, or an idea of which schema the instance has been validated with?
<annette_g> I think whatever gets validated should be machine-readable.
kcoyle: none of the use cases say that the instance should be valid
Jaroslav_Pullmann: the resource might link the the validation source to state formally what validated
kcoyle: I am nervous of people declaring that their instances are valid.
<ncar> me!
ncar: can I suggest that we vote on these separately
<kcoyle> PROPOSED: accept Profiles may be written in or may link to a validation language (ShEx, SHACL, XMLschema). ID41 as in scope
<ncar> 1+
<roba> +1
<annette_g> +1
<ncar> +1
+1
<SimonCox> +1
<DaveBrowning> +1
<LarsG> +1
alejandra: the first discusses validation language, so we need to adjust the wording
<alejandra> +1 with rewording, clarifying that it points to a document written in a validation language
Resolved: accept Profiles may be written in or may link to a document or schema in a validation language (ShEx, SHACL, XMLschema). ID41
<Jaroslav_Pullmann> +1
<annette_g> +1
<roba> -1 on basis of redundancy
<kcoyle> PROPOSED: accept as in scope Requirement: Profiles may be coordinated with/associated with validation schemas that would validate the instance data.
<ncar> -1
<roba> now i mean -1 on basis of redundancy
<alejandra> -1 as it is redundant and equivalent to the previous one
<DaveBrowning> -1 - redundant
<roba> the second...
annette_g: are people giving -1 to the first, or to the second proposal
kcoyle: to the second
<Zakim> LarsG, you wanted to ask about policy of duplicates
LarsG: do we have a policy about duplicate requirements, or are we normalising?
kcoyle: we can have duplicate or overlapping requirement - we can remove or blend during the UCR process
<LarsG> in that case +1
kcoyle: we haven't resolved this - do we think additional discussion will resolve? if not then we should drop
roba: I've been through the UCR and people can't trace back. I think we should avoid the UCR and just drop but make sure that the UCR traceability is clear
kcoyle: we need 1:1 or 1:n links. Can you link a single requirement to the use case?
… let's resolve in the following sense...
Resolved: Requirement: Profiles may be coordinated with validation schemas. is redundant; ID 48 will be linked to the same requirement
<annette_g> +1
+1
<roba> +1
<Jaroslav_Pullmann> +1
<alejandra> +1
<DaveBrowning> +1
<LarsG> +1
<ncar> +1
<kcoyle> ID2 https://docs.google.com/document/d/13hV2tJ6Kg2Hfe7e1BowY5QfCIweH9GxSCFQV1aWtOPg/edit#heading=h.bdr07yfzu6h
profiles must have identifiers that can be served with a response to an API or http request. ID2 (5.2)
<kcoyle> Requirement: profiles must have identifiers that can be served with a response to an API or http request. ID2
<ncar> +1
<annette_g> +10
+1
<alejandra> +1
<Jaroslav_Pullmann> +1
<roba> +1
<AndreaPerego> +1
<DaveBrowning> +1
Resolved: in scope: Requirement: profiles must have identifiers that can be served with a response to an API or http request. ID2
<LarsG> +1
<SimonCox> +1
<Jaroslav_Pullmann> ... but why mentioning concrete protocol/interface?
Jaroslav_Pullmann: does it mean profiles are resolved by URLs?
kcoyle: looking at the use case, it is specific to conneg
Jaroslav_Pullmann: the resolution isn't mentioned in the use case. are these concrete terms (API, HTTP request, etc) clearly in the use cases?
kcoyle: why don't we just say that profiles will have identifiers?
… but if you still have issues with the use case then put the discussion on github
kcoyle: the next is from that same use case (ID2)
<kcoyle> PROPOSED: accept as in scope Requirement: Clients should be able to determine which profiles are supported by a server, and with which content types. ID2
annette_g: here's where we start getting into conneg where the use cases seems to describe how conneg should work - it is getting circular. I would like a motivating use case. there have been some in the mailing list discussion
kcoyle: are you wanting the use case revised ?
annette_g: yes
Jaroslav_Pullmann: it goes into detail, but I understood the underlying motivation. we could make it more generally
<ncar> I volunteer
kcoyle: can someone take this offline and rewrite?
kcoyle: the use case must provide some sense of intent
<roba> the main thing UC should really do is specify pre and post-conditions..
kcoyle: you need to present the problem, not the solution
annette_g: it is a matter of finding the underlying problem
Action: ncar to re-create ID 2
<trackbot> Error finding 'ncar'. You can review and register nicknames at <https://www.w3.org/2017/dxwg/track/users>.
<ncar> ok, I accept!
LarsG: the point is the client needs to know if it can process the data, or not
<Zakim> LarsG, you wanted to give a reason
<annette_g> problem, with context
Jaroslav_Pullmann: is this a general motivation for profiles?
… to assure they are served in a way the client can use them
… do we have a statement of why profiles matter?
roba: profiles are a statement of interoperability
kcoyle: if you can't find that in any use cases, then you need to add one expressing this
<kcoyle> Requirement: There should be a way for a client to look up additional information about a profile.
kcoyle: ncar can you look at what Antoine did with the Europeana use case - rewrite and then re-extract the requirements
<annette_g> What I'm seeing a requirement for is a standardized way to indicate the
<annette_g> availability of alternative forms of a dataset with different profiles
<annette_g> and to enable the end user (human or script) to receive the most
<annette_g> appropriate one for their use.
<kcoyle> Profiles offered by a service must be discoverable through a machine-readable graph of metadata that describes what is offered and how to invoke the offered profiles. ID5
roba: this is just addressing the previous point about need for profiles, the difference being that it is a statement about macine readability
kcoyle: does the use of 'graph' limit it to RDF?
roba: it just refers to objects and associations
… there are databases without graph models, but they can be expressed in graph terms
<Jaroslav_Pullmann> .. +1 for dropping graph, and what about turning service to web resource: Profiles offered by a web reesource must be discoverable ..
kcoyle: we are getting to the point where this should be made less specific as it refers to solution space
Jaroslav_Pullmann: what about service, because conneg is related to web resources
roba: I think that resources may or may not be backed by a service -I'm happy as it reflects the use case
<roba> I'm agnostic - all resources are backed by a service.. so its kind of redundant and can be removed
<kcoyle> PROPOSED: accept as in scope PROPOSED: Profiles must be discoverable through a machine-readable metadata that describes what is offered and how to invoke the offered profiles. ID5
+1
<SimonCox> +1
<alejandra> +1
<roba> +1
<DaveBrowning> +1
<annette_g> +1
<Jaroslav_Pullmann> +1
<AndreaPerego> +1 - but I'm unsure about the MUST
<LarsG> +1
<AndreaPerego> Agreed. Thanks, kcoyle.
Resolved: accept as in scope Profiles must be discoverable through a machine-readable metadata that describes what is offered and how to invoke the offered profiles. ID5
<annette_g> It must be possible for profiles to be made discoverable through machine-readble metadata that describes what is offered and how to invoke the offered profiles.
<annette_g> yes
<annette_g> np
<kcoyle> Requirement: Profiles must support discoverability via search engines (UC 5.40) #222 (Github discussion) ID40
<SimonCox> must? or should?
<kcoyle> https://github.com/w3c/dxwg/issues/222
kcoyle: yes, it probably is a 'should'
<roba> shuld
<SimonCox> 'support discoverability' or 'be discoverable'
<ncar> +1 if should - we *should* aim for this
<alejandra> +1 if changed to should
<annette_g> +1
+1
<kcoyle> PROPOSED: in scope Requirement: Profiles should support discoverability via search engines (UC 5.40) #222 (Github discussion) ID40
AndreaPerego: still unsure about what this requirement is about
<alejandra> https://w3c.github.io/dxwg/ucr/#ID40
roba: it was about exposing DCAT content . the requirement was originally related to schema.org equivalents
<Jaroslav_Pullmann> would we like to distinguish both cases - profiles should be modeled in a way supporting their discoverability by search engines <-> search engines may use profile links to support the discoverability of compliant data instances
AndreaPerego: it still isn't clear to me - there can be alignment between dcat and schema.org, but we are dependent on how search engines work
… this is about best practices in the publication of metadata, and is related to the DCAT/Schema.org alignment
… we are unable to control how search engines index profiles
alejandra: I agree with AndreaPerego - it isn't a good idea to be specific abotu things that we cannot control, such as how search engines work.
<roba> this isnt about profiles, other than delivering schema.org instead of DCAT may be done by profile negotiation.
alejandra: there may already be a requirement for the same metadata expressed in different vocabularies
kcoyle: let's try to resolve this in the github discussion. when we return we might have a rewording (put that in the github discussion)
<alejandra> +1 to roba, the requirement should be about having profiles referring different vocabularies (different context files for the same data)
<SimonCox> RRSAgent: draft minutes v2
<annette_g> bye all!
<AndreaPerego> Thanks, and bye!
<Jaroslav_Pullmann> bye!
<alejandra> thanks! bye all
<LarsG> bye all
Succeeded: s/coordinated/related to/ ?