kcoyle: lots of regrets (northern hemisphere summer time...)
PROPOSED: Accept minutes from last meeting
0 wasn't there...
Resolved: Accept minutes from last meeting
<ncar> For https://www.w3.org/2017/dxwg/track/actions/148, I am waiting for the ProfileNeg meeting time to be locked in before I propose a meeting
kcoyle: please add comments to actions assigned to you
<trackbot> action-139 -- Antoine Isaac to 239 needs more discussion by conneg group and reading and comments by everyone -- due 2018-07-10 -- OPEN
antoine: can be closed
<trackbot> action-143 -- Jaroslav Pullmann to Construct examples of relations from real catalogs -- due 2018-07-12 -- OPEN
Jaroslav_Pullmann: save for DCAT meeting
<trackbot> action-145 -- Dave Raggett to Set up regular github dump to w3.org -- due 2018-07-17 -- OPEN
kcoyle: other groups get regular dumps to W3 so that should be possible
<trackbot> action-146 -- Dave Raggett to Look into adding a disclaimer for ip in the github readme to cover the wg for contributions by non-members as possible solution - or find a better solution -- due 2018-07-17 -- OPEN
kcoyle: has found examples of disclaimers from other groups
… can anyone volunteer to copy those to our repo?
PWinstanley: I volunteer
Action: PWinstanley to copy IP info to our github repo
<trackbot> Created ACTION-156 - Copy ip info to our github repo [on Peter Winstanley - due 2018-07-24].
<roba> simon posted report
noone who attended the last meeting is at this meeting...
ncar: waiting for new time for the profile negotiation group meeting
kcoyle: we should aim for asynchronous work due to time zone constraints
… we should also check in on our strategy for the profile guidance document
kcoyle: progress is slow since we're still discussing requirements.
… How can we move forward? kcoyle would want to hear those now or on the list
roba: +1 to start and then report back to the group although
… not all requirements are set yet
kcoyle: if there are requirements the group needs that aren't set yet we
… can add those to the next agenda
<kcoyle> LarsG: profile negotiation group report; no meetings for last 2 weeks; looking for new meeting time
<azaroth> Apologies for the logistic headache that I introduce!
ncar: six am could be OK
annette_g: suggests alternating meeting times
Jaroslav_Pullmann: We're working through the pull requests
kcoyle: Tries to keep track of rewordings etc.
kcoyle: Europeana requirement
<kcoyle> profiles may or may not be "exclusive" of other profiles
kcoyle: "some profiles may forbid the use of other profiles"
antoine: context: req comes from a time when we discussed if a dataset
… could comply to two profiles at the same time
… so we should make it explicit that we don't think so any more
roba: difference between forbidding things and having constraints that
… are mutually exclusive
antoine: the discussion at that time was closed-world: it's one profile or the other
roba: may be
<azaroth> +1 to RobA
antoine: yes, but that's a different level
roba: we need to reword this
Jaroslav_Pullmann: is it about technical incompatibility?
… we have discussed this and talked about preference rules. Is this
… a formal statement about compatibility?
<PWinstanley> +1 to ODRL similarity
kcoyle: this is very similar to what ODRL says (there is a way to set precedence)
… They can set rules if there are conflicts
<roba> so is this a profile language problem, or a profile description requirement?
annette_g: is the question perhaps more about to prevent a profile to
… have conflicting base profiles and not about the downstream
… processing? We should talk more about the downstream part.
antoine: this req was only to counter affirmations that data can be
… compliant with only one profile
roba: haven't we agreed on this already? All constraint languages
… should be able to handle this. If constraints are not compatible
… that should be explicit.
kcoyle: This req gives the option to construct profiles that are not
… useable with other profiles. Do we want that?
antoine: agrees with roba. in gh 287 there's a long discussion about this
… suggestion to rephrase to "may conform to several profiles at the same time"
<Zakim> azaroth, you wanted to be dubious
<roba> we can make a explanatory note that its possible that profiles may not be compatible, and that data must not be declared to conform to multiple incompatible profiles ?
azaroth: agrees with roba, antoine. Data can easily conform to several
… profiles at the same time. everything else seems unintuitive and useless.
PWinstanley: this is not about compatibility of data to profiles, it's about
… compatibility of profiles with profiles
azaroth: in the end it's always about data being compatible with profiles.
… Having a profile that is not compatible with other profiles is in the
… end that the data isn't compatible
annette_g: is anyone in favour of this prohibition?
roba: this is about expression and we can drop it since it's
… implicit through the constraints (we can have incompatible constraints)
… the req is out of scope since the profile definition mechanism
<kcoyle> PROPOSED: withdraw 12.2 as no meaningful use case found, nor methodology to implement
roba: should take care of that
<antoine> -1 until we accept the other requirement ;-)
<antoine> changing to +1
Resolved: withdraw 12.2 as no meaningful use case found, nor methodology to implement
<kcoyle> "A profile can be modular, with a given response made up of more than one module. A server can indicate that a response conforms to multiple, modular profiles. "
<azaroth> +1 to dropping "modular"
<kcoyle> “some data may conform to several profiles at once”
<roba> +1 to two simple requirements - they are different aspects
azaroth: there are two requirements
antoine: discussion in cneg goes this way, so we have agreement
kcoyle: breaking up into 4a and 4b
<annette_g> +1 to break it up
kcoyle: 4b will be the conneg one
kcoyle: 4a: some data may conform to several profiles at once
PROPOSED: Accept text " some data may conform to several profiles at once"
<annette_g> +1 to vote
Resolved: Accept text "some data may conform to several profiles at once"
<kcoyle> Proposed: Requirement 4 b) A server can indicate that a response conforms to multiple, modular profiles.
<annette_g> do we need modular in there?
<azaroth> +1 to deleting modular
<antoine> +1 to removing
<kcoyle> Proposed: Requirement 4 b) A server can indicate that a response conforms to multiple profiles
PWinstanley: Does this mean "one or more" or does it only apply to multiple?
annette_g: The server needs to be able to say that it's one or more
<Jaroslav_Pullmann> ".. to possibly multiple"?
<azaroth> No difference to me, assuming that there's another requirement that says servers can indicate the response conforms to a profiole
<kcoyle> Proposed: Requirement 4 b) A server can indicate that a response conforms to =>1 profiles
azaroth: should it be possible to say that a response conforms to zero known profiles?
<annette_g> +0 or more to that
<roba> thats what can means - vs must ?
Jaroslav_Pullmann: is this optional? we have a list-profiles operation
… this is a response to a particular request so we should change CAN to SHOULD
antoine: agrees that it could be possible that data conforms to zero profiles
<azaroth> +1 to going back to use cases!
antoine: but that's not the UC
roba: There might be legacy systems that cannot report which profiles
… the data conformst to
<azaroth> Also +1 to SHOULD for 1+ profiles
annette_g: this gets into a can-of-worms: the proposal for conneg was
… assuming registration of profiles. There might be unknown profiles.
ncar: wrote a new UC about no known profile. needs time to discuss this
<ncar> UC: https://github.com/w3c/dxwg/issues/306
<annette_g> annette_g: if profiles aren't registered, publishers would not know what profiles exist that their data might adhere to.
<azaroth> +1 to Lars
<kcoyle> LarsG: Open world for profiles: the data might adhere to profiles the server does not know about; say "zero profiles known to the server"
Jaroslav_Pullmann: can we add "compliant" server?
<azaroth> As the publisher of the data, we are explicitly saying there are no profiles we know of that this resource (or representation?) conforms to.
Jaroslav_Pullmann: we should only talk about compliant servers and supporting endpoints.
<azaroth> Is my hypothesis for a requirement, and I agree it needs further discussion :)
<roba> describing servers is a can of worms :-( - i think its just can vs should?
kcoyle: more work on server response
<roba> +1 antoine
antoine: we can improve the version with one or more
<annette_g> +1 to antoine
<azaroth> +1 to Antoine
antoine: but we need a requirement for zero or more profiles
ncar: there is more work to be done on server responses
… this is difficult area.
annette_g: registration of profiles is an issue
… we need registration
<kcoyle> Proposed: Requirement 4 b) A server can indicate that a response conforms to one or more profiles
kcoyle: conneg people should take this on
<roba> :-) no shared concept identity without a registration process IMHO
kcoyle: not ready to deal with this yet
<Jaroslav_Pullmann> +1 (can -> should?)
Resolved: Requirement 4 b) A server can indicate that a response conforms to one or more profiles
kcoyle: can -> should might be. We need more reqs for server responses
<roba> let conneg group discuss "should" and registration !
<Zakim> azaroth, you wanted to push back on registration
kcoyle: do we need a UC or requirements to deal with that?
azaroth: using URIs avoids name collisions. A registry is not required
… and might be antithetical to web architecture. And who should
… maintain this registry?
roba: registration collides with URIs and as long you can dereference
… the URIs to get descriptions we should be fine (that's what profileDesc is about)
annette_g: URIs don't prevent duplications or collisions (and there's link rot)
kcoyle: suggests that conneg group takes this on
… (no objections)
<Jaroslav_Pullmann> thank you, bye!