– DRAFT –
DXWG plenary

Admin

kcoyle: lots of regrets (northern hemisphere summer time...)

<kcoyle> https://‌www.w3.org/‌2018/‌07/‌10-dxwg-minutes

PROPOSED: Accept minutes from last meeting

<antoine> +1

<PWinstanley> +1

<azaroth> +1

0 wasn't there...

<Jaroslav_Pullmann> +1

<annette_g> +1

<roba> +1

Resolved: Accept minutes from last meeting

open actions

https://‌www.w3.org/‌2017/‌dxwg/‌track/‌actions/‌open

<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

action-139?

<trackbot> action-139 -- Antoine Isaac to 239 needs more discussion by conneg group and reading and comments by everyone -- due 2018-07-10 -- OPEN

<trackbot> https://‌www.w3.org/‌2017/‌dxwg/‌track/‌actions/‌139

antoine: can be closed

action-143?

<trackbot> action-143 -- Jaroslav Pullmann to Construct examples of relations from real catalogs -- due 2018-07-12 -- OPEN

<trackbot> https://‌www.w3.org/‌2017/‌dxwg/‌track/‌actions/‌143

Jaroslav_Pullmann: save for DCAT meeting

action-145?

<trackbot> action-145 -- Dave Raggett to Set up regular github dump to w3.org -- due 2018-07-17 -- OPEN

<trackbot> https://‌www.w3.org/‌2017/‌dxwg/‌track/‌actions/‌145

kcoyle: other groups get regular dumps to W3 so that should be possible

<kcoyle> https://‌lists.w3.org/‌Archives/‌Public/‌public-dxwg-wg/‌2018Jul/‌0114.html

action-146?

<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

<trackbot> https://‌www.w3.org/‌2017/‌dxwg/‌track/‌actions/‌146

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].

DCAT group report

<roba> simon posted report

noone who attended the last meeting is at this meeting...

profile guidance group report

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

<roba> +1

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

UCR

Jaroslav_Pullmann: We're working through the pull requests

kcoyle: Tries to keep track of rewordings etc.

Requirements

kcoyle: Europeana requirement
… 12.2

<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

<annette_g> +1

+1

<azaroth> +1

<antoine> -1 until we accept the other requirement ;-)

<azaroth> :P

<PWinstanley> +1

<roba> +1

<antoine> changing to +1

<Jaroslav_Pullmann> +1

Resolved: withdraw 12.2 as no meaningful use case found, nor methodology to implement

<kcoyle> # 4 https://‌docs.google.com/‌document/‌d/‌13hV2tJ6Kg2Hfe7e1BowY5QfCIweH9GxSCFQV1aWtOPg/‌edit#heading=h.ptcn17nv183e

<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> https://‌www.w3.org/‌2018/‌06/‌20-dxwgcneg-minutes.html

antoine: discussion in cneg goes this way, so we have agreement

kcoyle: breaking up into 4a and 4b

<azaroth> +1

<roba> aye

<annette_g> +1 to break it up

kcoyle: 4b will be the conneg one

<antoine> +1

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

<azaroth> +1

+1

<Jaroslav_Pullmann> +1

<PWinstanley> +1

<antoine> +1

<roba> +1

<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?

<roba> -modular

<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

<azaroth> +1

PWinstanley: Does this mean "one or more" or does it only apply to multiple?

<roba> _can_

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

<azaroth> +1

<PWinstanley> +1

<roba> :-) no shared concept identity without a registration process IMHO

kcoyle: not ready to deal with this yet

<roba> +1

<antoine> +1

<annette_g> +1

+1

<ncar> +1

<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

azaroth: 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)

<roba> +1

kcoyle: suggests that conneg group takes this on
… (no objections)

bye all

<Jaroslav_Pullmann> thank you, bye!