Dataset Exchange Working Group Teleconference -- 15 Aug 2018

<LarsG> trackbot, start meeting

<LarsG> Meeting: DXWG CNEG Telecon

<roba> * i'm chasing link too - computer restarted overnight

<roba> * my email can be a bit slow through its forwarding chain...

<roba> * still waiting - maybe * send it so it doesnrt get inuted - no one else here..

<LarsG> scribe: Rob Sanderson

<scribe> scribenick: azaroth

Confirm Agenda

larsg: Any comments?

<LarsG> https://www.w3.org/2017/dxwg/wiki/Meetings:CNEG-Telecon2018.08.15

azaroth: Looks great :)

Roba: Discussion of the use case around the CRS negotiation (and similar) ... we need to discuss it and then take back to plenary
... decide if it's useful. Need consensus here before going to plenary.

LarsG: Before or after requirements?

roba: Before, as the requirements in it can be discussed

azaroth: +1 to adding it

<roba> https://github.com/w3c/dxwg/issues/311#issuecomment-413204957

Approve minutes from last meeting

<roba> +1

<LarsG> https://www.w3.org/2018/06/20-dxwgcneg-minutes.html

link: https://www.w3.org/2018/06/20-dxwgcneg-minutes.html

<LarsG> +1

<ncar> +1

PROPOSAL: Approve the minutes of the last meeting: https://www.w3.org/2018/06/20-dxwgcneg-minutes.html

RESOLUTION: Approve the minutes of the last meeting: https://www.w3.org/2018/06/20-dxwgcneg-minutes.html

<roba> +1

Issues

SUBTOPIC: Use case for CRS Negotiation

roba: I'll kick off. There was a use case that emerged around negotation for coordinate reference systems and because we know from OGC experience that CRS is one of things constrained in profiles
... eg GeoJSON constrains it, combining JSON with other vocabularies that use the geometry / geography references
... profiles can constrain them, but also servers will advertise 1000 different CRS they support
... wouldn't want to publish 1000 profiles ... but it's also in profiles
... need to capture the requirements about profile negotation mechanism that it needs to be aware of other dimensions and specify the behavior
... don't think we had the requirement captured, need use cases for requirements, so tried to define it
... got a little bit skewed, but need to be aware of multiple orthogonal dimensions that can coexist with profiles
... need to specify the behavior
... Happy to have other editing of the wording of the use case, but need to get it agreed to put forward the requirement to the plenary

LarsG: Thank you Rob. Need to look up the use case to find the requirements ...

roba: there's 4 requirements

Larsg: First Seems clear , don't interfere

>> Profile negotiation mechanisms must support or safely co-exist with negotiation over other dimensions of data organisation.

LarsG: The second is about conforming servers

roba: Yeah, the profiles and servers need to be consistent with each other. Could be Distributions or just files

>>Where conformance to a profile is declared, and that profile specifies constraints over aspects of a data distribution, data distributions, including services must provide support for those constraints as minimum set of negotiable options.

LarsG: Basically, if you say you conform to the profile, you conform to the profile

roba: Originally just had the first requirement, but then there was questions about other CRS support
... so needed to capture that profiles have a minimal conformance requirement. Can support other things as well

azaroth: Might want to word it less DCAT specific wise?

roba: Yeah, we can tweak the wording :)
... [ ... ] thirdly, if you specify an aspect, it overrides the profile's default
... that seems to be the way profiles work in my experience.
... at least need to be able to support the pattern, should discuss if this is the only pattern

LarsG: I think this needs a bit of wordsmithing but do we do smithing first and then plenary or to plenary first

roba: One round of wordsmithing seems good
... don't seem to disagree, propose we accept the use case is valid and undertake to wordsmith in the issue
... before the next plenary in 2 weeks

+1 to that process

<ncar> +1

roba: Do we accept the requirements? they're quite strong

LarsG: need to read, seems like a good start

<roba> +1

ncar: support the use case but lots of things I don't understand yet
... eg how things interact
... I think it was the IETF and discussion about accept headers
... An open ended mechanism to add accept dimensions
... some mention some time ago about the general case of adding them. Could look that up.

roba: I suppose the behavior expectations would be useful -- evidence of expectations. Not going to nail down dimensions other than profile, so able to progress this.
... profiles aren't directly orthogonal to other dimensions, could cover all of them
... profiles of service behavior. Might say we need a profile for content separate from profiles of behavior
... currently they constrain specifications of any type

ncar: Could have an rdf resource that has different languages in it
... how does that work with language accept header?
... so not the only one
... Would need to look up expectations

roba: Could put a constraint in theprofile to say you must have an english label. That's what we need to worry about -- the non-orthogonality
... profiles go across dimensions, so need to specify behavior.
... I think profiles are thus a special case, due to this

LarsG: You said something important -- behavioral profiles, which is new to me in this context
... my view was always about the data constraint, not the behavioral. I think we need to discuss
... we've defined profiles as a set of constraints on top of media types

roba: The working definition is a constraint on a specification, that could be content or methods or whatever, it's open
... if I look at OGC web services, they provide multiple methods
... that interact. You can get service info of what is supported, and the user chooses what they want to do based on that metadata
... or the client on the user's behalf. the typical profile will specify the metadata as well as the payload response
... or the naming conventions of the resources that can be accessed. Service profiles address that expanded scope

LarsG: yup, definitely a need

azaroth: (explains use case)

LarsG: Is it documented?

azaroth: Yes I put it in a comment in GH on the relevant issue

roba: [...] profile on the content response, but don't need to necessarily subclass them. Might emerge as a requirement in the process.
... could add to the profile description language
... negotation about content, profile must be about content :)

azaroth: (echoes back UC and requirements) good, +1

PROPOSAL: Accept the use case as provided at https://github.com/w3c/dxwg/issues/311

<ncar> +1

<LarsG> +1

<roba> +1

RESOLUTION: Accept the use case as provided at https://github.com/w3c/dxwg/issues/311

roba: You triggered a thought, Lars. Good to discuss this stuff :) In the OGC we have the concept of modular specs, we define the conformance target for those specs
... an abstract data model, the target is a schema. So you write a schema that conforms to the data model.
... soft typing of the nature of the profile. Not a controlled list, specified in words
... seems like a requirement there for the scope of the profile, but haven't thought through the mechanism
... typing, soft typing, human description or what.
... don't think we need to worry too much about it in conneg, as we don't know the scope is relevant to the content

azaroth: xxx

roba: If you ask for the australian govt profile, it might specify that the service is up 100% of the time. Can't negotiate on that, clearly.
... just a common sense thing

LarsG: Good, have something to take to the plenary

roba: Should have an action -- I get lost in the words sometimes, so good to have some other people to work on the wording
... capture the sense for the broader audience

<LarsG> ACTION: roba to reword the UC at https://github.com/w3c/dxwg/issues/311

<trackbot> Created ACTION-179 - Reword the uc at https://github.com/w3c/dxwg/issues/311 [on Rob Atkinson - due 2018-08-22].

<LarsG> close action-179

<trackbot> Closed action-179.

<LarsG> azaroth to review the requirements at https://github.com/w3c/dxwg/issues/311

<scribe> ACTION: azaroth to review the requirements and suggest edits

<trackbot> Created ACTION-180 - Review the requirements and suggest edits [on Robert Sanderson - due 2018-08-22].

SUBTOPIC: #264, #265

LarsG: First is Metadata about server profile support can be used for discovery and mediated traversal via content negotiation.
... Second is Enable the ability to negotiate the metadata profile via http, similar to the negotiation of metadata formats today.
... in the google doc, question was if those are content negotiation or the profile description

roba: First one is supported by dcat with conformsTo on a Distribution
... so I think it's an issue for dcat too, where the groups' scope join

need to describe the resources in terms of what is supported

scribe: it's a requirement that should be taken on
... they asked to review it
... do we agree? I think we do, or I do personally. Needs to capture the driving requirements

ncar: Need to rush off, apologies

SUBTOPIC: #266 Return http link headers using the following relationship types

<LarsG> azaroth: #266 is too much solution.

<LarsG> roba: Agrees, we need a cleaner requirement

<LarsG> ... "There must be a way for the server to indicate to the client what the

<LarsG> ... of the conneg process was including the following aspects ..."

<LarsG> PROPOSED: Accept #10 with roba's rewording

<roba> There must be a way for the server to indicate to the client what the result of the conneg process was

<roba> +1

<LarsG> +1

RESOLUTION: Accept #10 with roba's rewording

<LarsG> SUBTOPIC: #267

<LarsG> azaroth: this is not a conneg issue

<LarsG> roba: more an issue for profile description

PROPOSAL: CNEG subgroup doesn't consider this to fall into our scope but otherwise accepts it as reasonable requirement

<LarsG> +1

<roba> +1

RESOLUTION: CNEG subgroup doesn't consider this to fall into our scope but otherwise accepts it as reasonable requirement

PROPOSAL: Accept as-is requirements in GH issues #264 and #265

<LarsG> +1

<roba> +1

RESOLUTION: Accept as-is requirements in GH issues #264 and #265

LarsG: Thanks to everyone. Need to have email discussion on some of the comments.

roba: First is reiterating the requirements, second needs more thought

<scribe> ACTION: LarsG to look at detail of second comment and report to group

<trackbot> Created ACTION-181 - Look at detail of second comment and report to group [on Lars G. Svensson - due 2018-08-22].

Adjourn

<LarsG> trackbot, end meeting

- DRAFT -

Dataset Exchange Working Group Teleconference

15 Aug 2018

Attendees

Contents

Confirm Agenda

Approve minutes from last meeting

Issues

Adjourn

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output