Meeting minutes
Approval of last week’s minutes: 1
<pfps> minutes look OK to me
<AZ> +0 (I was not present)
<ktk> PROPOSAL: Approve last week's minutes.
at either of the 2 meetings
<ktk> +1
<gtw> +1
<lisp> +1
<olaf> +1
<pchampin> +1
<pfps> except for the "biweekly" thing
<pfps> +1
<niklasl> +1
<Dominik_T> +1
<tl> +0 (not present)
<TallTed> +1
<doerthe> +0 (not present)
<fsasaki> +1
<pchampin> pfps, good point, I'll look into that
RESOLUTION: Approve last week's minutes.
<william-vw> +1
Identifying issues to solve before CR 2
pchampin: the W3C calendar says biweekly, which does not make sense
… I'll fix it
ktk: pchampin, could say a word about horizontal reviews
pchampin: each horizontal group has questions
… we will send the questionnaire to the appropriate groups
ktk: some things from these groups do not apply to us
… but we must fill this in before they do their work
Issues related to IRI w3c/rdf-concepts#223 w3c/rdf-n-triples#73 w3c/rdf-concepts#169
AndyS: I started looking at it
… we have a reference name, IRI reference
… we must put some things in Turtle etc to add an anchor to it
… in reference to lines 4, 5 and 7
<gb> Issue 169 Relative IRI Reference should bind to the irelative-ref production (by gkellogg) [ms:CR] [spec:editorial]
<gb> Issue 223 RDF Reference IRI (by afs) [ms:CR]
<gb> Issue 73 IRI resolution requirements (by gkellogg) [ms:CR] [needs discussion] [spec:substantive]
<gb> Issue 89 Different parsing of the same absolute IRI with or without base IRI (by Tpt) [ErratumRaised] [ms:CR] [needs discussion]
ktk: any questions for Andy?
… other updates?
… we are waiting for some input from Dorthe on 102 on Semantics
Pull Request 76 Add profile parameter (by pchampin) [ms:CR] [needs discussion]
pchampin: issue 76 on n-triples is about adding a profile parameter
… it would be good to have a way to signal that the document comply with a given profile
… I copied the text from JSON-LD where there is a profile parameter
… this would be hard to add after CR
<Zakim> pfps, you wanted to ask about line 8
pfps: I agree with AndyS's comment that n-triples must be dead simple, but now it's less
AndyS: I am not opposed to it, but I don't think it is as simple as pchampin pretend it is
… we have to look at the whole context to see what are the consequences
<niklasl> https://
<niklasl> The 'profile' Link Relation Type
AndyS: RFC 6906 defines the profile optional parameter but refers to 5988 that is the link header
<niklasl> https://
pchampin: I agree n-triples must be dead simple and I think this keeps it simple
… but I agree consequences on conneg may be unforeseen
… the RFC defines profile as a link in header
… it encourages adding mediatype as a parameter
… anyway, I don't want to push too much and block CR
… but would be a missed opportunity
Dominik_T: I agree with pchampin, nothing too complicated
pchampin: if the concern is about conneg then I understand
… we have the option of using the Link header
… we would need a URL for the canonical form
… then there would not be a problem with conneg
<pfps> I'm still on the "mostly harmless" view here
w3c/rdf-semantics#102
ktk: let us address 102 on Semantics
doerthe: we are still discussing this issue but not yet finalised
w3c/rdf-semantics#139
ktk: issue139 on Semantics
doerthe: we still have to do something on this issue
… a problem with Appendix A now is that we may create an infinite model, not something we want to have, so still some progress to make
Issue 133 appendix B update needed (by pfps) [ms:CR] [propose closing] [spec:enhancement]
doerthe: I would like to keep it, but it is ok to close it if others want to
pfps: this is a very technical appendix
<TallTed> any reason not to make it a NOTE, which may or may not get future attention?
<niklasl> +1 for remove with a pointer to the section in 1.1
pfps: not very important to keep it, but if it is there and someone notice it is wrong, it may become a problem
<ktk> 1?
pfps: there is no consequence for any RDF-related software
ktk: should we make it a note?
pfps: that would be a separate document
enrico: we could put it away for CR and possibly put it back
TallTed: as a note, it does not need to be correct
… it just needs the group to have some level of consensus on it
pchampin: whether it should be a separate note: it is an informative section so it could be put again after CR; both options are possible
doerthe: I want to keep it, but I want to have a corrected version
Pull Request 160 Fixes correctness of Appendix A (from issue #139) (by franconi) [ms:CR]
enrico: this is similar to 139 that was discussed before
pfps: I'm worried that some members of the WG are asking for fundamental changes to the semantics
… there was something again on changing things related to asserted triples, but we need to close the discussion now
pchampin: the issue was closed, so what is still coming back?
<niklasl> It's w3c/
<gb> CLOSED Pull Request 220 Annotations on asserted triples are based on operational semantics (by rat10) [ms:CR]
pfps: this is saying that there is something lacking in Semantics, but are we done now with it, or should we still do something about it
ktk: we said in previous meeting that the discussion should be closed
lisp: I made a respond but I did not reopened the issue
ktk: any other things on Semantics or Concepts?
<ktk> https://
ktk: there are a number of issues with "propose closing"
Issue 128 map the annotation syntax to `rdfs:states` (by rat10) [enhancement] [propose closing]
tl: with the proposal we double the count of triples, with one reified triple for each triple
… using rdfs:states we do not have this problem
<pchampin> FTR, the email that tl is referring to: https://
tl: either we double the triples or we double the properties
… we may not want to close it now
pfps: I don't see why doubling is involved.
pchampin: my response to the email on the ML
<pfps> the question is how much data is needed for rdf:reifies plus assertion vs just rdf:states.
pchampin: was that dealing with graphs is not in our charter
… I think we have good foundation for dealing with graphs, but that's out of scope for the WG
… I don't think this very much related to the rdf:states thing
<pfps> The latter needs data for the stated triple plus data for the rdf:states triple
<pfps> The former needs data for the stated triple plus data for the rdf:reifies triple
enrico: doubling is necessary if you want to have an asserted triple and also in triple term
<pfps> So what is the difference?
enrico: if you use "states" and a triple term, you don't have the triple in the graph to retrieve it with queries
<niklasl> +1 to what Enrico said. Especially optimization. Stronger semantics enables less materialization.
<pfps> A non-optimized implementation might store two copies of the asserted triple in the rdf:reifies version, but that is in no way necessary.
tl: I closed the issue (128) but I hope we can continue the discussion in the mailing list
Issues marked as "proposed closing"
ktk: I'll remove the flag "propose closing" on 133 on semantics
we can close w3c/rdf-schema#29
<gb> CLOSED Issue 29 addition of rdf:RDFSource on the rdf: vocabulary (by pchampin) [propose closing] [spec:substantive]
ktk: can we close w3c/sparql-query#182 ?
<gb> Issue 182 Cover triple terms in definition of RDFterm-equal (by hartig) [propose closing] [spec:enhancement]
olaf: yes I confirm it can be closed
ktk: w3c/rdf-schema#35 can be closed too
<gb> CLOSED Issue 35 Visual model (by riannella) [propose closing] [spec:editorial]
ktk: can we close w3c/rdf-concepts#172 ?
<gb> Issue 172 Define the notion of "atomic term" (by pchampin) [propose closing] [spec:editorial]
pchampin: yes we can definitely close it
ktk: can we close w3c/rdf-turtle#97 ?
<gb> Issue 97 Undeterministic roundtripping between Turtle-star annotations syntax and N-triples (by rat10) [propose closing]
tl: yes it can be closed
ktk: can we close w3c/rdf-turtle#114 ?
<gb> Issue 114 why is the term constructor optional in production `reifier`? (by pchampin) [propose closing]
pchampin: let's close it
<ktk> s/seperately/separately/
<ktk> s/comnply/comply/
<ktk> s/resond/respond/