<LarsG> apologies+ Antoine
<roba> * ugh now i have to find a webex password
<LarsG> https://www.w3.org/2017/dxwg/wiki/Meetings:CNEG-Telecon2018.10.10
LarsG: Main topics are progress on FPWD and might need to discuss new meeting time
… end of DST in Europe in 3 weeks, Australia is ... weird
… Anything else?
ncar: All the effort is around FPWD, think we need to discuss that
<LarsG> PROPOSED: Approve minutes
<roba> +1
<ncar> +1
<LarsG> https://www.w3.org/2018/09/26-dxwgcneg-minutes.html
<LarsG> +1
+0 (not present)
Resolved: Approve minutes
<LarsG> https://www.w3.org/2017/dxwg/track/products/4
ncar: we did have a couple ...
LarsG: Product list only has three
… our product is product 4
ncar: I can report on these
… 212 is make an issue for profile version, have done that. Issue #391.
… question is does it appear in the document somewhere?
<LarsG> ISSUE-212?
<trackbot> Sorry, but ISSUE-212 does not exist.
ncar: answer is ... yes it does :) It's a singleton issue that we might consider removingt
<LarsG> ACTION-212?
<trackbot> ACTION-212 -- Nicholas Car to Create an issue for profile version representation or not via identifier for w3c conneg doc -- due 2018-09-19 -- PENDINGREVIEW
<trackbot> https://www.w3.org/2017/dxwg/track/actions/212
ncar: in the PR version.
… Rendered version of the PR document ... might talk about that in a minute
… Appears in two places. In its own section, and the issue list. So can close action.
LarsG: Fair enough!
<LarsG> close ACTION-212
<trackbot> Closed ACTION-212.
ncar: 214 is add a section to the doc to lay out recommendations for FPWD. Was confused, made a PR last week, but forgot what else we wanted to put in
… made a section but there's no content in it.
… so have followed to the letter, but haven't worked out the details
LarsG: downside of 10pm, can't remember either!
ncar: I looked at the minutes, but couldn't work it out. Noted in the action that I suggested we remove it
… no other group has such a section
… the FPWD seems like a whole document thing, rather than a section in the doc
larsg: DCAT people have it fairly easy as they copied the old spec and noted what to do differently
ncar: I think we either had to write down the recommendations, or to write down what FPWD needs to tick boxes for structure etc.
roba: Could close and ignore if the latter, and for the former we've done the issues
ncar: can just remove the section
LarsG: Should be the former, don't need a meta discussion in the document about the document
ncar: A section about recommendations?
roba: Doc is a recommendation. So just specify normative requirements.
ncar: Yeah, just get rid of the section
LarsG: Would leave us with [list of sections]
ncar: That's where we're missing stuff. Link ...
… HTML rendering of the PR
… rawgit is shutting down, so using a worse service that doesn't do things like letting you click through links
… imagine section 5 is removed. Related work describes the profile guidance and IETF draft
… Important things are after the related work, there's two sections. Need something to test conceptually and specifically
… abstract model is what is conneg in general, and put in a GH issue to discuss
roba: Definitions and diagram.
ncar: must be some abstract way to describe the functionality, some sort of UML thing.
roba: a sequence diagram
ncar: Yeah, not a trouble for the group. Abstract, then for specifics see the sections / related docs
… put in issue 463 for the implementation question
… puts a serious task on the doc to define things, rather than pass on to other docs
roba: would propose that negotiation by http terminology, then extract those as definitions, write a sequence diagram with those terms
… and the query string argument implementation pattern, have the issue of whether we have a canonical version or if we map to those arguments
… could be to list the profiles, the server has to tell the user which arguments are used for conneg
… either have a metadata problem, or a canonicalization problem :)
… thing to start with is extracting the key concepts from ietf work
… happy to take an action to do the sequence diagram
… good to make it fit with the information diagram. If you do the model, I'll do the sequence, and lars can extract key elements?
ncar: Can I go back one -- with those sections does that look like we're covering the scope required for FPWD?
… have intro, motivation, abstract model, and specific realizations
… then test suite and implementations
… only now do we have the full amount to cover
https://www.w3.org/TR/annotation-model/
<LarsG> azaroth: test suite and implementation report don't have to be in the document
<LarsG> ... they can develop separately from the spec
<LarsG> ncar: where is the link?
<LarsG> azaroth: at the top of the spec
<LarsG> ncar: Is that respec magic?
<LarsG> azaroth: [checking github...]
respect code: "implementationReportURI": "https://w3c.github.io/test-results/annotation-model/all.html",
<LarsG> ncar: do the tests live in a different github repo?
<LarsG> azaroth: several test-* repositories in W3C
<LarsG> ... bit of a pain to use since you have to download everything separately
<LarsG> ncar: The SHACL implementation report is a separate section
<LarsG> ... more lightweight to push and pull against a smaller repo
<LarsG> ... don't know if how SHACL want to continue maintaining this repo
<LarsG> ... what is your recommendation?
<LarsG> azaroth: This should be discussed at TPAC
<LarsG> ncar: at meeting yesterday we were asked to submit topics for TPAC
Action: azaroth to submit topic for face to face meeting about test runner/ results repositories
<trackbot> Created ACTION-231 - Submit topic for face to face meeting about test runner/ results repositories [on Robert Sanderson - due 2018-10-17].
<LarsG> ... and then we need to discuss the removal of section 9 in current ED
<LarsG> roba: Specifications should be in a testable form, that's at least OGC policy
<LarsG> ... test suite is just a version of the requirements
<LarsG> ncar: So we just refer to an executable script to do the testing?
<LarsG> ncar: if we take "two implementations" seriously, is it OK just to link
<LarsG> ... to the implementation report?
<LarsG> azaroth: No, it's part of the process
<LarsG> ncar: Then §9 can go
<LarsG> azaroth: annotation model implementation report was written to make it easy
<LarsG> ... to go from CR to PR
<LarsG> ncar: Then we can remove §9
Action: ncar to remove section test suite and implementation sections
<trackbot> Created ACTION-232 - Remove section test suite and implementation sections [on Nicholas Car - due 2018-10-17].
ncar: If we can answer the question that the debate came from, if we remove that section and make it a link ... does that look like the structure for FPWD?
… [sections]
… added privacy / security considerations section
+1 to that list, minus test suite :)
LarsG: That could work
roba: It's only FPWD, can tune it
ncar: would someone encountering the doc get a sense of what we're talking about and how things will be dealt with
… would they look at the sections and think it was sensible
… heading towards FPWD
LarsG: think it'll work. Before it's published, it needs to be reviewed by the WG anyway
… be signed off by plenary
… perhaps in Lyon
ncar: Keen to make sure we're stepping through it properly
… okay, will make those changes today
… will put in a fake link to an implementation report but will be there in concept
roba: just a stub page
ncar: Another PR, but assuming that goes through, we can submit to plenary
… have looked at w3c validation system to ensure I have all the things correct ... not been pleasant
… validation tool doesn't work with the doc as we write it, it requires the static html
… e.g. post JS rendered, lots of false errors
… dont' have a title, but can see that we do
roba: It probably looks for css class declarations
ncar: tried to improve some of those
… e.g. informative sections are tagged
… adds in the css itself
… tried to follow that as best as I can following things like SHACL, but not critical for FPWD
LarsG: You click the respec button and click export, then put it through the validator?
ncar: Oh, I was doing DOM inspection
… that would have saved some time
LarsG: not sure if that is the way it works
azaroth: Yup, that's how it works :)
ncar: pubrules is a pain ... have to reference something that's hosted
… can do that but need to do it by hand, can't just upload a chunk of text
… could make some suggestions ;D
… what we've written looks similar to recent specs, so validation errors should be minor and solvable
… not a barrier to FPWD
… if agreed, I'll go ahead with the edits.
… can cycle back to who should do what, w.r.t. abstract models and realizations
roba: proposed three actions - Lars to extract definitions from IETF, ncar to create minimal information model from that, and then for me to create a UML sequence diagram
ncar: Would that be ... a diagram of ...
roba: the information elements in the model if we need it. if there's a relationship in the definitions between a profile and the media types they're available in, we need some abstract name for that relationship
… so when you implement it, it's there
… got to tease out those "things".
… nothing we don't already do, but don't have it yet
ncar: would be interesting, as looks like a generalized version of the model i've been using for alternative views
… trying to achieve the same task. has view, format, with relationship ... looking at the terminology and implementing a model for it, would be a better informed version of thatt model
… related to the profile ontology
roba: exactly right, would make the relationship visible
ncar: would be dependent on Lars' action
roba: a minimal list of definitions and descriptions of the critical sequences
LarsG: definitions of ... what?
roba: for example if the process says that the client asks for something from the server with a name ... e.g. a header that gets back a list of profile identifiers, that's what we need ot have in the diagram
… extract those terms for a diagram
… not sure what status those definitions have. can review them for stability
LarsG: Ruben's definitions will go in there too
… for us to figure out!
… I can extract my definitions and create diagram from that for FPWD. If need to change it later, no problem
azaroth: synchronization between IETF and W3C docs??
ncar: depends if it was a breaking change or not
… if it breaks the conceptual model, would need to change the way things are described
roba: Try to keep in sync until we reach a decision point
azaroth: updates about IETF doc?
LarsG: Herbert has opted out. Ruben has promised to start working on it again in same week as TPAC
Action: Lars to extract definitions to form basis of abstract model
<trackbot> Created ACTION-233 - Extract definitions to form basis of abstract model [on Lars G. Svensson - due 2018-10-17].
Action: ncar to use definitions to create abstract model diagram and text
<trackbot> Created ACTION-234 - Use definitions to create abstract model diagram and text [on Nicholas Car - due 2018-10-17].
Action: roba to create sequence diagram from abstract model and definitions
<trackbot> Created ACTION-235 - Create sequence diagram from abstract model and definitions [on Rob Atkinson - due 2018-10-17].
ncar: that's all I had to discuss at the meeting :)
roba: One item to put up for feedback ... number of activities in the OGC space have been looking at the use of JSON-LD. Has a mechanism for a context ... hope Rob S can enlighten us ... trying to figure out relationship between context and profile
… sort of a namespace for a profile. Perhaps a full expression of a profile, like a schema
<LarsG> azaroth: A context document in JSON-LD is a mapping of RDF predicates to JSON keys
<LarsG> ... e. g. DC title and you want to use title in JSON, you map dc:title to title
<LarsG> ... in the context (document)
<LarsG> ... it's not a definitional document, so you cannot define new terms
<LarsG> ... several tricks that can be done in order to create the desired JSON structure
<LarsG> ... without constraining the triples
<LarsG> roba: can that express constraints as in a profile?
<LarsG> azaroth: not quite. can see why it's possible to think of them as constraints,
<LarsG> roba: feels like constraints/profiles
Example: {"@context": {"dc": "http://blablaba.org/ns", "title": "dc:title"}}
<LarsG> azaroth: I don't think of them as constraints.
<LarsG> ... it's closer to namespace prefixes, but you can map the whole term
<LarsG> ... it's also possible to import complete contexts and merge them
<LarsG> ... and not create new terms or mappings but re-using what's there already
<LarsG> ... some JSON document conforms to a profile if it uses the names
<LarsG> ... specified in the context.
<LarsG> roba: so it's necessary but not sufficient?
<LarsG> azaroth: correct
<LarsG> ... part of the work in JSON-LD WG because others want to do conneg
<LarsG> ... based on frames etc, saying "I want this particular part of the graph
<LarsG> ... to look like this"
<LarsG> roba: so is this emerging?
<LarsG> azaroth: yes.
https://www.w3.org/TR/json-ld11-framing/
<LarsG> ... part of the community group, not WG
<LarsG> ... now it's about creating an API
<LarsG> roba: we probably need to bring this into focus in DXWG, seems relevant
<LarsG> ... how do we do that?
<LarsG> azaroth: kcoyle has agreed to have a 90 minute block for joint discussion
<LarsG> ... with JSON-LD WG
<LarsG> ... and how that impacts conneg (how to request a specific format for a
<LarsG> ... JSON-LD doc)
<LarsG> ... (hope I got that right...)
LarsG: 2 minutes to talk about meeting time?
… from my point of view, this time slot is good
ncar: this time is good for me
azaroth: good for me
roba: fine for me too
:)
LarsG: And for me an hour earlier
<LarsG> Bye all
Succeeded: s/ncar/larsg/
Succeeded: s/teh/the/
Succeeded: s/hte/the/