<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
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
<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
+1
RESOLUTION: Approve the minutes of the last meeting: https://www.w3.org/2018/06/20-dxwgcneg-minutes.html
<roba> +1
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
+1
<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
+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
+1
<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
+1
<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].
<LarsG> trackbot, end meeting
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/the of/the result of/ Default Present: Rob_Sanderson, roba, LarsG, ncar Present: LarsG Rob_Sanderson roba Found Scribe: Rob Sanderson Found ScribeNick: azaroth Found Date: 15 Aug 2018 People with action items: azaroth larsg roba WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]