Meeting minutes
Approval of minutes from the last two meetings: 1 , 2
ora: I had one thing on minutes. I was identified as "ora" and "ora3" due to irc issues.
TallTed: only a problem if somebody [else] identifies as "ora3".
ora: ok. that's fine.
<ora> PROPOSAL: Approve minutes of last two meetings
ora: any other issues?
<gkellogg> +1
<Dominik_T> +1
<william_vw> +1
<ora> +1
<eBremer> +1
<ora> +1
TallTed: small typo. not a big problem.
<TallTed> +1
<william_vw> that's some typo :-)
<pchampin> +1
<doerthe> +1
<niklasl> +1
<pfps> +1
RESOLUTION: Approve minutes of last two meetings
Proposed resolution by Semantics TF (cont.) 3
ora: I was not able to attend sem TF meeting. wanted to know where we are with this.
… I guess we have regrets from enrico. niklasl were you at the meeting?
niklasl: yes.
… we had agreement.
william_vw: we agreed to use reificationProperty.
… and inferencing associated with it.
ora: my suggestion is that we make that one of the topics of next week's discussion.
… may be able to vote on a resolution.
… don't want big discussion in this meeting.
TallTed: I'm fine with doing that. I want an explicit "this is the proposition we're going to vote on", not a link to a section of minutes.
… I can't consider minutes as a proposal.
<william_vw> +1
ora: agreed. that's a good idea.
… enrico is not here, but maybe we assign him an action on this. he can produce a proposal before next week's meeting.
niklasl: he sent regrets for tomorrow as well, I believe.
ora: can we still have the meeting?
niklasl: good idea to try to make some summarizing of the proposal to prepare for next Thursday.
… I'll show up.
ora: hammer out something concrete tomorrow to decide next week.
ora: I don't think there's anything else at this point.
Proposal for next week's discussion
ora: that resolution should be part of next week's discussion. hopefully not the whole meeting.
… anything else? last meeting before TPAC.
… regular meeting during TPAC week has been cancelled.
… would it make sense for us to have a discussion next week figuring out whether we're prepared for TPAC?
… I'm working on slides. We could review those. I'll send them beforehand.
… Could take feedback.
… "TPAC Preparation" meeting?
niklasl: I think that's a good idea.
… I tried to write down something regarding named graphs. Haven't gotten that far. Could merge that into yours...
… or try to hammer it out beforehand?
… I'll be at a conference next week. Will send notes before.
… Can look tomorrow.
gkellogg: Since named graphs were brought up, we were talking yesterday what JSON-LD-star looks like.
… there's an out-of-date community report.
… as we get into it, we need to add keywords -- reifies, annotations --
… hard to distinguish "reifies" from what graph does.
… that leads to the notion that a named graph could be represented using reification.
… that might be a good way to explain the basis. no semantics in that case.
… reifier has a type with no semantics.
… that's something we might want to think about some more.
ora: great idea. it's been a subject that has worried me.
ora: do you want to write a short paragraph and send it to the mailing list?
gkellogg: sure.
… the other realization from that is that triple term in subject position (we don't allow) -- that is difficult to express in JSON-LD.
… just as another data point.
pchampin: the idea of this discussion was to prepare the joint meeting between our WG and the JSON-LD WG.
… can post something on mailing list, but also idea was to discuss at TPAC.
AndyS: I think there's 3 cases we have to draw out.
… reification of single triple.
… graph literals/graph terms
… named graphs
… tends to be confusion between grpah literals and named graphs.
… normally doesn't matter, but recipe for chaos.
niklasl: that's very important to mention.
… don't mention how much we can say.
… I know doerthe wanted to say somethign about graph terms in N3
doerthe: yes, I'll be there tomorrow. can explain some things on N3.
… can discuss.
niklasl: I want to say somethign about that.
… relation to triple terms wouald be something to discuss.
ora: enough to talk about tomorrow and next thursday.
… who all is coming to TPAC in person?
gtw: I am.
niklasl: I'll be remote.
gkellogg: other RDF-adjacent groups there. we'll get more attendence.
ora: I think that's one of the benefits of TPAC.
TallTed: worth noting that there's collisions with adjacent groups.
… like Verifiable Credentials on Thursday and DIDs on Tuesday
Review of pull requests, available at 4
ora: what PRs do we have?
w3c/rdf-tests#135
gkellogg: first one has been open for a bit. new tests for updated turtle.
… need even more on that.
… waiting for someone else to have an implementation.
… AndyS is working on updates to his parser. Hopefully we can get an approval after that.
AndyS: about at the stage where I can run those tests.
ora: so not to merge yet?
gkellogg: yeah, let's wait until someone else is passing the tests.
w3c/sparql-query#153
AndyS: line item 7, I did an update for grammar of query for 1.2 features.
… triple terms, annotation syntax, language directions.
… just the grammar, not the text or functions.
… believe it's reasonably complete.
… we should wait. difficult to review just grammar changes.
… hoping we could give it a week or so. then merge. then take corrections on that.
w3c/rdf-turtle#68 and w3c/rdf-trig#33
gkellogg: second item (updates to turtle). I think that's ready to merge.
… then item 5 on trig. this started by Dominik_T some time ago. I did some updates to align with Turtle.
… needs more approvals.
… substantive change which is recent. but it does mirror the updates to turtle.
ora: you're saying someone else should take a look before a merge?
gkellogg: yes. look and approve. then we can merge after that.
AndyS: I can. Have done changes to the trig parser.
w3c/sparql-federated-query#20
ora: what about federated sparql error fix?
AndyS: it has 3 approvals.
ora: I think we should merge it. Not sensing that it needs waiting anymore.
AndyS: I can sort that out.
ora: any others for today?
Issue Triage, available at 5
gkellogg: the "needs discussion" tab has 8 things in it. better place to start.
ora: we need to be better at picking those things and having those discussions.
… on these focussed meetings.
… quite a bit of editorial stuff.
AndyS: going through for TPAC, if we could generate more resolutions that would make it easier to remain motivated for the editorial stuff.
ora: let's pick some of those items to work through during TPAC.
ora: there are a number tagged "sparql". what was the idea of the "sparql" tag?
AndyS: a lot of those are on rdf-tests. picking up labels from that. not labels from the WG.
ora: should they have some other tag?
… for easier identification.
AndyS: easier to not include them at the moment. a lot of them are hang-overs. errata items should be on the specs themselves.
gkellogg: from the issue you can remove it from the project.
TallTed: on the dashboard, mouse to the left, disclosure triangle gives you actions. "delete from project".
pchampin: doesn't delete it from repo. just from project (dashboard).
AndyS: I'll clear them up afterwards.
ora: there are a bunch that don't have any tags.
Any Other Business (AOB), time permitting
ora: somebody asked me recently about best practices for editing an ontology and using git. comparisons between consecutive versions.
… if you're really editing the text file, not much of an issue. anybody have experience using other tools?
TallTed: first question. if your ontology is serialized as RDF/XML, it's going to be one kind of bear to edit. If n-quads, depends on ordering which bear that is to edit.
… comparing different versions, git is not suited to comparing graphs.
… especially with multiple serializations.
ora: what is the advice I could give?
TallTed: use an ontology editor.
… use the right tool for the job.
<pchampin> Wimmics/
pchampin: I'm not sure if that's exactly what you were looking for, but there is a project developed in research team in INRIA.
… set of continuous integration tools for onotlogy projects.
… implementation of good practices published as a research paper for onotology development.
pchampin: about the problems with graph serialization. we now have spec for graph canonicalization.
… I did a script that first canonicalizes files, then diffs those.
… even if bnode labels have changed, order has changed, if they represent the same dataset, the diff will be empty.
… but if there's a change, diff could be huge.
… better than nothing.
… when the diff does not involve bnodes, cool to have canonical version. text diff does a pretty good job.
ora: I ask because I was thinking the canonicalization spec in principle could solve this problem. didn't know what the best practice would be.
pchampin: I believe that the diff tool that git uses can be configured based on file types. might be possibel to tell git to use particular kind of tool to detect differences.
AndyS: someone was asking about reading and writing RDF data so it was more git friendly.
… we spent some time discussing. conclusion that he wants to get the diffs reasonably stable.
… he also wants to keep it in the order it was originally written. which is a problem with canonicalization approach.
… one way of handling it is there's a toolkit which specializes in preserving order of read/write in RDF.
… retaining original bnode labels, etc. gives stability. can see changes.
<pchampin> fsasaki, I don't think there is a python implementation of rdf-canon, so the script is relying on other tools being installed, so it's a bit brittle
AndyS: I think it's based on keeping graphs in insertion order.
… can edit and see where things have been added.
… What i took away from that, slippery slope to have a set of tools that are focused on achieving that.
… a general toolkit doesn't do it. Anything using hashmap is very hard. If it reorders things, order is not preserved at all.
pchampin: meta discussion - I have developed a tool that might be interesting for the group.
… a program that takes the minutes and locates all the places where github issues were discussed. puts GH links in the thread.
… I used to do that manually during the CG days. Error prone.
<AndyS> https://
<gb> CLOSED Discussion 2672 Consistent/reproducible TTL and TRIG formatting with Jena? (by fkleedorfer)
pchampin: I am experimenting with an IRC bot that can do this.
… I will use it at the end of this meeting. If people think it's a good idea, we can generalize its use.
… working with systems team to run the bot.
… involves some discipline in how we manage issues in the discussion.
… feel free to chime in with suggestions
ora: AOB?
niklasl: about visualizations related to presentation. in rdf concepts document we have a few SVGs.
… I was looking at another viz. style in document about n-ary relationships.
<niklasl> https://
niklasl: it uses boxes and arrows. dont' know if anybody has references to some kind of best practice or most used conventions.
… interesting to talk about that. if I'm going to write note on beset practices, good to visualize stuff in a cohesive way.
ora: there's quite a bit of work in diagramatic represetations .
… I have a former colleague who wrote papers on that. Will dig them up and send them.
… introduces a graphical/visual language.
… visual idioms always mean the same thing.
… maybe worth taking a look at.
<niklasl> https://
niklasl: looked at this before. initially going to make a turtle syntax highlighter. got out of hand.
… turtle with rounded corners.
… wouldn't work in official documents.
… looking for something workable for most people.
ora: adjourned.