DXWG plenary

17 July 2018

Meeting Minutes


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


<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

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

antoine: can be closed


<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


<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


<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


Jaroslav_Pullmann: We're working through the pull requests

kcoyle: Tries to keep track of rewordings etc.


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


<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


<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


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

Summary of Action Items

  1. PWinstanley to copy IP info to our github repo

Summary of Resolutions

  1. Accept minutes from last meeting
  2. withdraw 12.2 as no meaningful use case found, nor methodology to implement
  3. Accept text "some data may conform to several profiles at once"
  4. Requirement 4 b) A server can indicate that a response conforms to one or more profiles
Minutes formatted by Bert Bos's scribe.perl version 2.41 (2018/03/23 13:13:49), a reimplementation of David Booth's scribe.perl. See CVS log.


Succeeded: s/rteport/report/

Succeeded: s/sentences/requirements/

Succeeded: s/responsed/responses/