Meeting minutes
Approval of minutes from the last two meetings: 1 , 2
ora: anybody have concerns about minutes?
AndyS: the first one's next meeting link goes to 404. otherwise good.
<pchampin> I will fix the 404 link
TallTed: there was no SPARQL call that week.
pchampin: Will fix issues.
<ora> PROPOSAL: Approve minutes of last two meetings
<ora> +1
<AndyS> +1
<fsasaki> +1
<olaf> +1
<lisp> +1
<TallTed> +1
<pchampin> +1 (for the one where I was present)
<gtw> +1
<gkellogg> +1
<niklasl> +1 (for second where I was present)
RESOLUTION: Approve minutes of last two meetings
Proposal for next week's discussion
ora: before we get into specifics, pchampin and I had discussion about switching from alternating schedule to meetings where we do CR-related review.
… this is our highest priority at the moment.
<lisp> +1
<fsasaki> +1
ora: maybe pchampin can edit the schedule accordingly.
<TallTed> +1
ora: will do what we did last week in every meeting.
pchampin: to clarify, we have admin meetings. the other ones are called focus meetings. propose switching back to focus meetings for everything.
… will approve minutes every week, and then focus on CR-related items.
… will simply remove the focus meetings from schedule. calendar will still have two alternating meetings, but with same name.
… could swtich back in future.
ora: anything else we want to talk about the topic selection? now no reason for this topic selection the way we've been doing it.
… I think that means we're good. Future meeting agendas will reflect this.
Review of open actions, available at 3
pchampin: first one on the list is basically done. can close the action.
… what remains to be done can be tracked on PRs.
… the second line can also be closed. issue 183.
<pchampin> w3c/rdf-concepts#231
<gb> Pull Request 231 remove normative language from Security Considerations (by pchampin) [ms:CR]
pchampin: PR in (w3c/rdf-concepts#231)
<gb> Action 168 add rdf-interop to rdf-common, and propagate that to other repos (on pchampin) due 2025-06-26
pchampin: was going to propose closing two issues, but have to think about it. having them always open makes them basically invisible.
… the one that is paused I propose to close it.
<Zakim> pfps, you wanted to ask whether the PRs for #168 should be merged
pchampin: the one on short names has some work to do. I will do this.
pfps: does that mean we should merge the PRs for the first thing on dashboard?
pchampin: for me, they are good to merge.
… basically updating the lists of related documents.
… updating some bibliography. primary links to published version. also fixes issue talking about rdf-star WG.
… suggest editors merge the changes.
… suggest merging on top of these, as CI actions will break otherwise.
… doesn't prevent merging
<gb> Issue 14 Enable Github pages on this repository to load by URL rather than local copies (by niklasl)
pfps: that should fix error messages on my two PRs for semantics?
pchampin: I can check.
TallTed: I'm hesitant about closing issues before PRs are merged.
… standard practice is to merge and then close issue.
… I don't think the amnesia about seeing same issue/PR listed all the time should be a reason to close the issues.
… there being an open issue indicates that it hasn't been handled yet.
… as we get towards CR, reviewing no remaining open issues is part of the flow.
… they should remain until all PRs for the issue are merged.
gkellogg: updating these common files is painful. we'll have to do it more.
… niklasl came up with mechanism to avoid doing it. step in CI that copies things in.
… I suggested we hold off on that until after CR, but that's only the case for concepts, semantics, and n-triples.
… it's time to try to improve that workflow for remaining repos.
pchampin: responding to TallTed, I see your point. I see values in both ways, so no strong opinion.
… about the one that was paused, there is currently no issue. I proposed keeping it open because it might re-appear.
… lots to do when we re-create a repo. this issue doesn't serve a purpose, so I was proposing to close it.
ora: when you say your checklist, I hope that ends up on the wiki somewhere.
pchampin: that's my checklist as staff contact for things only I can do.
ora: might be valuable to have it visible somewhere.
<niklasl> w3c/
<gb> Issue 14 Enable Github pages on this repository to load by URL rather than local copies (by niklasl)
niklasl: regarding gkellogg's proposal, I agree that it might be useful to enable that for other specs. holding off on the 3 going to CR now.
<TallTed> it's fine to close the issue re repo creation. and I agree that the checklist should be preserved somewhere for any future staff contact, for, e.g., RDF & SPARQL 1.3 or 2.0
<niklasl> Also, +1 to close that paused one.
ora: my understanding is that we'll deal with PRs first before closing the action items.
Review of pull requests, available at 4
ora: I think there was one more action item.
… line item 5.
… I think we tried to discuss this, but Dominik_T was not in the meeting.
… anything to say about this?
Dominik_T: asking about rdf-schema?
ora: yes.
Dominik_T: I created PR and waited for some responses. Then apply some changes. For the last two days, the PR is accepted.
… you can see the reorganization in the spec.
ora: there is an open...?
Dominik_T: yes. you can look at the spec.
ora: we'll get to that when we look at PRs.
w3c/rdf-concepts#229
pfps: I think we have come to rdf:JSON that is acceptable to everbody.
ora: great!
pfps: definition section says "unordered maps" with note about implementation.
ora: we can merge this.
pfps: yes. thanks to pchampin for the wording.
<TallTed> that being w3c/
<gb> Pull Request 229 change definition of rdf:JSON (by pchampin)
pfps: I'll fix that so it closes the issue as well.
w3c/rdf-concepts#232
ora: where are we with abstract data model/syntax issue?
lisp: I was and I did.
… my change was a consequence of listening to comments last week.
… suggested to me that the wording was too ambiguous.
… my first attempt was to pick a term and use it. see reaction.
… that was not appreciated. several concerns.
… pulled back that PR and made another one.
<TallTed> latest is w3c/
<gb> Pull Request 232 revise to use "abstract data model" to unify "abstract syntax" and "data model" (by lisp)
lisp: changes the usages which are about an abstract data model to "abstract data model".
… documented doesn't really have an abstract syntax in it.
… doesn't have concrete data model.
… now a PR with substitutions with "abstract data model" but no reactions so far.
ora: urge everyone to take a look at this.
… want to hear comments
niklasl: I've looked at that. In middle of review.
… I will post review.
… I think it's good to see it spelled out.
… The PR as it stands keeps abstract syntax in one place which is good. Has been there for ~20 years.
pfps: This changes the title of document. That's not a problem for W3C process(?)
pchampin: I don't think it is.
ora: docs identified by URL, not title, I suppose.
pfps: I'm fine with title change.
ora: Considering we do this, should I put a paragraph in the RDF New document informing people about our thinking on this?
<pfps> +1 to put something in RDF New
<gkellogg> +1
ora: let's record an action for me to do that.
<pchampin> +1 to mention this change in rdf-new if we abandon (or tone down) "abstract syntax"
lisp: I devoted no thought to the consequences of this with respect to other documents.
… attempt to be consistent with the term.
… to be consistent, the title had to change.
… with respect to explanations, considering adding paragraph which could go in this document.
ora: might still be a good idea to put something in RDF New.
<niklasl> +1 I have that action in mind.
ACTION: ora to put a note in RDF-new that "abstract syntax" is now "abstract data model"
<TallTed> we probably will need a consistency check across the other documents
<gb> Created action #176
pfps: Every place we refer to this docuemnt, we say "RDF Concepts".
… bibliography has the full title.
… they will change semi-automatically?
pchampin: they should.
pchampin: once a new draft is published.
ora: we don't touch bibliographies.
pfps: nothing has to be changed for title change.
<pchampin> RDF Semantics contains one occurrence of "RDF abstract syntax" that is not generated and would need to be updated
ora: urge everyone to take a look at what James has done.
lisp: in terms of terminology, it's not a casual change.
pchampin: I found one mention of "RDF Abstract Syntax" not generated by resepc.
… in a number of places, we talk about "concrete syntaxes".
… is it a problem? I don't think it is, but might want to consider.
niklasl: I noticed that, too. Perhaps we might want to keep the abstract syntax in more than once place.
… that will be part of the Note. Not part of this PR.
ora: homework for next week.
… if everyone is happy, James can merge.
<TallTed> maybe replace "concrete syntaxes" with "concrete serializations"?
ora: I think it's OK to talk about concrete syntax. Emphasizes we're talking about textual representations.
<pfps> I'm going to change the "abstract syntax" mention in Semantics, as it really means just parts of an RDF graph.
TallTed: maybe replace "concrete syntaxes" with "concrete serializations"?
gkellogg: it feels backwards to me. serializations formed by serializing something out. syntax is the way you write things that can then be parsed into data model.
TallTed: take abstract data model and serialize it into a concrete serialization.
gkellogg: that's correct. but many ways to serialize a graph that would not be the automatic result of running an automatic serializer.
<niklasl> +1 to gkellogg, I think syntax is relevant here.
ora: understand, but sounds nit-picking to me. to clarify, gkellogg are you saying if I write turlte in emacs, I'm not serializing anythign?
gkellogg: depends on definition of "serialization".
ora: suggest everybody think about this. we can bring this up next week.
ora: other PRs?
gkellogg: n-quads and turtle.
w3c/rdf-concepts#231
<gb> Pull Request 231 remove normative language from Security Considerations (by pchampin) [ms:CR]
pchampin: PR 231 is ready. Related to actions we talked about earlier.
… been approved by editors. I think it's ready to ship.
ora: happy to have you merge it.
<TallTed> I've got ~39 rdf-shapes notifications, plus all the sub-repos, needing review
TallTed: need to ask for more time.
ora: just ping pchampin when you're ready.
TallTed: will put approve on whatever I've gone over.
pchampin: I'd ask editors to merge this after TallTed's approvel as I'll be away until next Friday.
gkellogg: I see TallTed's approval in the review.
TallTed: I don't know which PRs are being discussed. If I approved, then merge it. If things have changed since the approval, please don't.
ora: subtopic: w3c/rdf-n-quads#80
gkellogg: document we're focused on is n-triples, but echos through all turtle-like specs. I've been applying changes.
… will also need similar changes to rdf-tests
w3c/rdf-concepts#223
<gb> Issue 223 RDF Reference IRI (by afs) [ms:CR]
AndyS: I'd like to get this issue sorted out (rdf references).
<niklasl> +1
AndyS: it tries to outline what makes a good reference despite what you can write in IRIs.
… can't be completely enforced, but gives a sense of what would make a good one (stable, agrees with what reference is).
<Zakim> pfps, you wanted to mention sparql entailment
pfps: couple of changes on SPARQL entailment which are editorial.
… somebody found a bug in document.
… referred to wrong rule.
… will merge unless somebody complains.
AndyS: I've gone through SPARQL documents. May merge some of the changes despite long-running actions.
ora: maybe a few minutes in issue triage.
Issue Triage, available at 5
TallTed: pfps, I don't know which entailment PRs you were talking about.
pfps: they are merged in already.
… for sparql entailment.
TallTed: it doesn't appear in the dashboard.
pfps: because no more PRs on it.
<gb> MERGED Pull Request 41 fix wrong entailment rule in RDF entailment example (by pfps) [spec:editorial]
<TallTed> looks like 40, 41 (link above), & 44
gkellogg: IRI resolution requirements in n-triples. Something we've got to figure out sooner rather than later.
… n-triples#73
<gb> Issue 73 not found
w3c/rdf-n-triples#73
<gb> Issue 73 IRI resolution requirements (by gkellogg) [ms:CR] [needs discussion] [spec:substantive]
gkellogg: issue about when do you resolve an IRI that looks like it's already in resolved form.
… two ways to do it: always resolve every IRI against document base which means you can't talk about IRIs with dot segments.
… n-triples only allows that form, but if turtle took the same document and resolved the dot segments out, and n-triples didn't do that, it would be an inconsistency.
… could avoid saying what to do if the document is not in the correct form.
ora: should be discussed.
<TallTed> uh oh. "period-segments"? "decimal-segments"? "full-stop-segments"? "dot-segments"?
ora: how often does this show up? I can't ever remember seeing URIs like that.
… have to be complete, but I'm curious.
<TallTed> I've seen them plenty. including both `/./` and `/../`
gkellogg: tests are full of IRIs with dot segments. Mostly with relative IRIs.
<AndyS> "dot segments" is the terminology in RFC 3986
gkellogg: Ruben had created comprehensive tests for this. Specific test has always been commented out because implementations vary widely.
<pchampin> "IRIs SHOULD be stable for the resolution algorithm"
<TallTed> "unicode full stop"or simply "dot" "." vs"unicode middle dot" "·"
<niklasl> Yes, it might somewhat tangentially relate to w3c/
<gb> Issue 14 Enable Github pages on this repository to load by URL rather than local copies (by niklasl)
gkellogg: Other places with requirements saying "documents must use this form" and if they don't, then signal a warning. Alleviates having to have normative tests since it's garbage data.
niklasl: gkellogg touched on what I was going to say. I think different implementations regarding dot segments would be useful to do research.
… curl for instance handles dot segments. http aware tools get rid of it. Better for n-triples to mandate normalization, otherwise we have this problematic variation.
gkellogg: my implementation does not do that. At one time it did, and it created problems for users.
AndyS: niklasl, your case is different for establishing a target URI. URIs are mutable in RFC.
… very careful wording in there.
<TallTed> google has no search that finds dots in urls ... so clearly they don't exist
<pchampin> regrets for next week