Meeting minutes
Announcements and newcomers
pchampin: no newcomers
… no announcements?
Open actions
<pchampin> https://
pchampin:
the open actions are in PRs to be discussed later in this meeting
pchampin: hence, skip to the next point
Pending Pull-Requests
pchampin: four PRs grouped in one points
<pchampin> https://
pchampin: Ghislain not here
… any updates on PR 205?
AndyS: That PR was raised against the wrong branch
… one massively squashed commit
… at least one comment on the other version of the PR
… closed that version
… something in the checking was not working
gkellogg: no the check is okay
… might have been something in the JSON manifest
AndyS: something was not committed
gkellogg: some issue in terms of equality of the manifests in the different formats
pchampin: will ping Ghislain
… the manifests should be isomorphic
AndyS: two checks now, haven't there been three earlier?
… let's take this offline
pchampin: That PR has been lingering a while
figure in §1.3
pchampin: next subtopic: figure in Sec.1.3
… two proposals made
… unfortunately, the second one is not rendered properly in the preview
<pchampin> https://
pchampin: which might explain why everyone favored the other one
… PR 213 tried to capture the links between the bubbles by means of words
… with eclipses
<pchampin> https://
pchampin: simply uses HTML tables
… PR 214 has an SVG in the background
… which is not visible in the preview
… but in a local clone
<rivettp> are you able to show the diagrams via Zoom?
pchampin: i.e., HTML table with SVG in the background
<Fabio_Vitali> I see no star
pchampin: somewhat hacky
<TallTed> I prefer the first (213), even knowing about the background lines (on 214). I would like it even better if 5 could be a bit lower than 4 & 6, to naturally sketch more of an arc from 3 to 7.
<Fabio_Vitali> Ah I see
pchampin: a similar figure may also be added as background in the first proposal
<Fabio_Vitali> I think that in 213 the top bubble (the subject) is too close to the second layer, and seems part of it. Raising it just a little bit could help, I think
pchampin: perhaps we use 213 if everyone is okay with it - there are more important topics
AndyS: the one with SVG look good
… (just checked it locally)
… screensharing now
TallTed: still prefer 213
pchampin: agreed, the grouping in 214 is subjective
… any strong preference anyone?
<TallTed> strong 213, lines could help, moving box 5 to the next lower tr would improve things
pchampin: otherwise will try to merge the results
… no objection
RDF vocabulary
<pchampin> https://
pchampin: next PR is about the RDF vocab section
… posted recently
… let's not talk about it too much now, because few people may have had the time to look at it in detail
… idea of that PR: moving things around (no new content) but making some things normative
… substantive changes is the semantics of TEPs to also cover rdf-star:Triple
gkellogg: use of TEPs refers to the range of such a TEP, right?
pchampin: no, it can be used for both, subject and object
… there might be corner case in which one would want a TEP that applies only to either the subjects or the objects but not both
… we could add something for that but that would make everything more complex (more vocab needed)
<Fabio_Vitali> TEP?
<pchampin> Transparency-Enabling Property
gkellogg: okay, but the design trade-off should be captured as a note
<Fabio_Vitali> thanks
olaf: I wouldn't go for seperating domain-wise TEPS and range-wise TEPs
… this is too much added complexity.
… I discussed the use-case for TEPs with somebody,
… and it was not obvious what happened in the examples
… (the added leading zero in the literals).
… Using different IRIs instead would make the difference more visible.
AndyS: agree that D-entailment is not so suitable for this example
… would have prefered the text to be non-normative
<Fabio_Vitali> from the outside, I can tell that the Linköping is clear in what it entails, but less so on the rationale (why is this needed?) Superman's example is clearer on the rationale
AndyS: mixing the discussion of TEPs with the other vocabulary parts is not a good idea
… because TEPs is something that people may disagree with, which is not so much the case for the other vocab terms
… put the TEP part into a separate (sub)section
pchampin: yes we could do that
… last time we kinda agreed to move the semantics of the TEP vocab into a normative section
AndyS: Triple, Graph, and Source are minimal; TEP does not fit into a minimal subset of such a vocab
pchampin: we have many issues related to the vocabulary
… some should be considered as: no agreement
… the one for the service descriptions are still needed and should be added
<gkellogg> Perhaps "Conceptual Vocabulary" and "Entailment-enabling Vocabulary"
<AndyS> +1
pchampin: regarding the TEP, agreed that it is more controversial than the aforementioned minimal set and, thus, should be presented somewhat separate from the minimal set
… rdf-star:Triple is also entailment-enabling
… Graph and Source are not
… prefer to keep the vocab semantics in one part
… hence, split the vocab section
Issues we may defer to the future WG
<pchampin> https://
pchampin: have marked some issues as "for later"
… should we discuss these issues?
AndyS: 199 is out of scope - Vladimir agreed
pchampin: so, we can close it? ...or mark as "discussion"
<pchampin> https://
pchampin: 170 could be closed
… because the problem has been addressed by means of the TEPs
… we shouldn't try to do more here but, instead, leave that to the WG
<pchampin> PROPOSAL: close #170 as addressed by the section on TEPs
<gkellogg> +1
<pchampin> +1
<olaf> +1
<AndyS> +1
<TallTed> +0.9
<Doerthe> +1
<rivettp> +1
<Fabio_Vitali> +1
TallTed: reason for +0.9 is lack of consideration
Resolution: close #170 as addressed by the section on TEPs
pchampin: issue about RDF/XML interpretation as RDF-star ...
… proposal was to reinterpret the ID in RDF/XML for RDF-star
… don't think it should be added to the report
+1
AndyS: if we were going there (rather not!), it should actually be more general -- RDF reification to RDF-star
<pchampin> https://
pchampin: there was also an issue from James
… wants complete grammars for all media types touched by the report
… I would rather not do that
<AndyS> +1 to pchampin.
gkellogg: yes agree, including it in the report would be burdensome
… however, we may include extra EBNF grammar files and link to them from the report
pchampin: good idea, and that should address James' concern
… Gregg, do you have such files already?
<fabio> yes
gkellogg: give me an action
AndyS: at such late stage, make these EBNF files non-normative
… EBNF does not include parser actions
Action: gkellogg to create a PR with text version of the EBNF grammars
pchampin: will fix the minutes ;-)
… What should be done for the future WG?
… thanks everyone for today
<fabio> Thank you
<AndyS> Thanks!
<fabio> bye
pchampin: talk again in two weeks
<Doerthe> bye
Bye
<TallTed> s/ACTION: gkellog to create a PR with text version of the EBNF grammars//
<TallTed> s/ACTION: gkellog to create a PR with text version of the EBNF grammars/ /