Meeting minutes
Enrico: Meeting for tomorrow will be canceled.
ora: Next up: approval of last week's minutes.
Scribe: Thibodeau, Ted (alternate: Zimmermann, Antoine)
<pchampin> TallTed unable to scribe, rubenswork volunteers
Approval of last week's minutes: 1
<pfps> minutes look fine to me
<pfps> (except for a typo or two that don't need attention)
pchampin: I did a small fix in the minutes. Some links to GH were incorrect.
… I will add some information on how the bot works.
<pchampin> #1
<gkellogg> #48
<pchampin> #23
<pchampin> ghurlbot, status
<ghurlbot> pchampin, the delay is 15, issues are on, names are on; and no repositories are specified.
pchampin: If we mention an open action, this should be recognized by the bot. But it appears to not work now.
<pchampin> ghurlbot, help
<ghurlbot> pchampin, I am a bot to look up and create GitHub issues and
<ghurlbot> … action items. I am an instance of GHURLBot 0.3.
<ghurlbot> … Try "ghurlbot, help commands" or
<ghurlbot> … see https://
Repository: w3c/rdf-star-wg
<pchampin> #23
<ghurlbot> Action 23 work on conformance proposal (on Antoine-Zimmermann) due 23 Feb 2023
pchampin: If we mention a number, the bot will find it in the default repo, and mention it.
<pchampin> rdf-schema#9
<ghurlbot> Pull Request 9 json datatype added (domel) needs discussion
pchampin: If we want to mention another repo, we can do so as well.
… Hopefully this improves the minutes in the future.
<ora> PROPOSAL: Approve last week's minutes
<pchampin> +1
+1
<ora> +1
<Dominik_T> +1
<gkellogg> +1
<afs> +1
<pfps> +1
<AZ> +1
<enrico> +1
RESOLUTION: Approve last week's minutes
Discussion and vote on chairs' process proposal on PRs (forthcoming)
<ora> https://
ora: I tried to articulate what the rules for PRs could be.
<pfps> Policy looks fine to me as long as the labels are applied conservatively.
ora: Any thoughts or comments?
<pfps> It should also be possible resolve needs discussion through email or GH discussion.
ora: Should we state explicitly if something requires discussion?
<pfps> Agreed - as long as there is some approval for a substantive change, the change can go through without discussion.
pfps: Substantive changes being covered don't need discussion. If everyone agrees, remove the discussion label.
… There are some grey areas in labels.
<pchampin> +1 to resolve 'need-discussion' offline when possible
<gkellogg> My comment was that substantive changes where the discussion would be the same as another approved substantive change don't necessarily require discussion.
pfps: Descriptions you see are poor. gkellogg has better descriptions for labels.
pchampin: Descriptions should be consistent across repos.
… I can easily update them.
ora: I find it good and ironic that we have so much control over the control vocabulary, considering our group.
ora: Should we go over all labels?
pfps: Would be good to put it in a wiki. No need to discuss it further.
ora: Someone needs to collect this in a wiki page.
… I propose that we accept the rules in my email as a way to go forward with PRs.
gkellogg: Every repo allows you to check label definitions, so we may not need another wiki page, as they are getting out of hand. Wikis are unwieldy.
ora: Those definitions now match?
gkellogg: Once pchampin does his magic, they will.
pchampin: I suggest to reflect gkellogg's definitions, as they are better than mine.
<pfps> Fine by me.
pchampin: I also don't see the benefit to also copying this to a wiki page.
ora: We should have single source of truth.
… To avoid it getting out of hand again.
TallTedd: I'm looking at an open issue, and the tooltip of the label, but they are truncated, where is the full view?
<gkellogg> https://
gkellogg: You can go to issues > labels, and view the descriptions.
TallTedd: So they can not be seen on specific issues.
ora: Then we just need to ensure that they remain in sync across repos.
gkellogg: We can probably trim in the labels we have.
… We can have a non-wiki file to drive the tooling to sync labels.
pchampin: I have such a file, so I can share it.
ora: So if there is disagreement, that file serves as source of truth.
ACTION: pchampin to put in the repo the "source of truth" for labels
<ghurlbot> Created action #49
ora: I like us to agree on our PR merging rules.
gkellogg: Some issues are enhanc or substantive, and if they are not discussed, they can only be merged in the next meeting.
ora: We go one meeting cycle before merging.
gkellogg: I agree.
<ora> PROPOSAL: Adopt Ora's proposal for PR merging: https://
+1
<ora> +1
<pchampin> +1
<afs> +1
<Dominik_T> +1
<gkellogg> +1
<pfps> +1
<AZ> +°1
<enrico> +1
RESOLUTION: Adopt Ora's proposal for PR merging: https://
Review of open actions, available at 2
ora: I think creation policy issue marker is the same as the one for merging PRs.
… So it's complete.
pfps: I worry that issues can come up and be resolved without WG oversight.
… For example: RDF JSON datatype that affects multiple documents. I would mark it as substantive change.
… We should not be able to get into such a situation.
ora: You noticed it, and brought it up, and can mark it as requiring discussion.
pfps: But if it's considered editorial, oversight window is too small.
ora: These things can be reverted if needed.
pfps: Ok, but I would ask people to be considerate in their labeling.
… Many things are truly editorial, but many straddle the line.
… Another example is the documents getting many more normative references.
… We should avoid this if they are non-normative.
… We should be more conservative in marking things editorial.
gkellogg: RDF JSON is editorial.
… The other one is enhancement.
… Normative vs informative: there was some email exchange, and should be up to the editor to choose.
pfps: I agree with gkellogg
… This just a warning.
… All editors should go through their documents to check if all are still correct.
<pfps> I'm OK with the current situation now.
ora: Mistakes can happen, but can also be reverted. I think we all understand, and can go forward. I have faith that we can handle this now. Let's go forward with the rules as we understand them.
Review of pull requests, available at 3
Repository: w3c/rdf-star-wg
ora: 3 PRs require discussion. Who wants to start?
rdf:JSON datatype
gkellogg: We discussed rdf:JSON
… RDF schema change should be consistent with that, and issue marker.
… We should still decide to go forward with rdf:JSON datatype, but no need to get into that.
… We should discuss on adding an issue marker.
<pfps> OK, but it would be useful to add the discussion about rdf:JSON to some upcoming group meeting
gkellogg: It's more of an enhancement at this point. Are we taking on the work to add rdf:JSON datatype? Because it has impact on semantics.
… We need to discuss this at some point.
AZ: The change to the range to rdf:predicate is not consistent with the RDF semantics.
… The semantics says that range is rdf:Resource, and change proposes to say in RDF schema that range is rdf:Property.
… And we should follow RDF semantics, which is normative.
<pfps> Good point on RDF Semantics
pchampin: There was a discussion on mailinglist on this point.
… Result was that it should not be a change to rdf:Property.
… Good that we reached same conclusions.
… I commented this on the change.
… The change would be purely editorial.
pfps: I agree.
ora: PR can be merged?
pchampin: Not until my suggested change is integrated.
pchampin: This may have already happened.
Dominik_T: I just accepted the proposal.
ora: No more discussion on this needed?
<pfps> Fine by me
pchampin: Mark it as editorial.
gkellogg: I suggest that this be changed to be consistent with other issue marker.
<pfps> It would be useful to have something that both changes can point to.
Dominik_T: If you gkellogg have time, please do it.
ora: All editorial PRs can now be merged.
… 2 substantive changes, implies we discuss them.
2 outstanding substantive PRs on n-quads and n-triples
gkellogg: One is n-quads, one in n-triples. First removes remaining bits to normalization ... literals.
… Previous text limited text on characters.
<pchampin> rdf-n-quads#27
<ghurlbot> Pull Request 27 Update the use of ECHAR and UCHAR in canonical N-Quads. (gkellogg) spec:substantive
gkellogg: Would be better to have those characters be escaped.
… Canonicalization has done a lot of discussion around this already.
… We should also review n-quads document.
… n-triples issue, should make it consistent with n-quads.
<pchampin> rdf-n-triples#19
<ghurlbot> Pull Request 19 Updates canonical N-Triples to be consistent with N-Quads. (gkellogg) spec:substantive
gkellogg: We are repeating ourselves across these documents, so maybe we should solve this, but standing on their own is also good.
n-triples should be equivalent to n-quads, without graph name.
… It's useful that n-quads document is comprehensive, but we can add a note saying that it is consistent with n-triples.
<pfps> The working group has resolved to do this work https://
ora: I like that. Can you add that note.
gkellogg: Yes
<afs> +1 to standalone documents for this matter.
gkellogg: Because we discussed it, can we merge? Or wait another week?
ora: We should still wait for people not in this meeting. So we wait one cycle.
<Zakim> pfps, you wanted to mention that editors should keep up to date on PR for their documents
gkellogg: I am only editor on RDF/XML.
… Problematic for all editors to agree.
ora: Makes it simple.
<pfps> if you are the only editor then you are free to disagee with yourself
gkellogg: I appreciate if people look at it.
Define "First Public Working Draft" (FPWD) process: 4
afs: We were scheduled for FPWD end or March. What is the process?
pchampin: To get it published, we need to make a transition req to W3C webmasters.
… We need to prepare a static version.
… without all JS stuff.
<gkellogg> publication_snapshots/FPWD
pchampin: We can create a folder fpwd/ where this static html is created.
… exporting this with the right parameter changes the status.
… We need to decide on a date.
… I make the transition request to webmasters.
ora: This is on a per-spec basis?
pchampin: We don't have to do all at once.
… We could also do a group transition request, but there is no requirement.
… We could train on one or a few specs.
ora: We can try on one first
gkellogg: I don't know if we need to wait for everything to be perfect.
… RDF concepts is a good one to start with.
… Once it's published, it can be referenced.
… Local bib references can be removed.
<Zakim> pfps, you wanted to ask about inter-document references
gkellogg: I would like to get all out close together, or at the same time.
pfps: I think we have reference loops between docs.
gkellogg: Once they are published, not a problem.
pfps: If concepts refers semantics, this should be published at same time?
gkellogg: Until we update local bib references, this won't be a problem.
… Acceptable for FPWD.
… We should minimize time between doing this.
… Good to prepare them all for publication.
… And perhaps only published subset that are acceptable./
pchampin: Echidna allows us to publish new WD when pushing to main branch.
… Allows WD to remain up-to-date.
… Refers to current state, not necessarily concensus.
… We need a group decision to set this up.
gkellogg: Let's discuss further via email.
gkellogg: You can specify pubdate as query parameter.
afs: Doesn't change filename, but what is in the doc.
ora: Let's continue via email.