Meeting minutes
<ora> For obvious reasons I will not volunteer...
pchampin: new people on the call !
… but not in IRC
<pchampin> and no microphone
Announcements and newcomers
pchampin: announcements anyone?
… none, it seems
<TallTed> that's ancient!
Open actions
<pchampin> https://
pchampin: open actions on me
… still late on the charter for a possible WG
<pchampin> https://
pchampin: another open one is about SPARQL service description
… not addressed yet
<pchampin> https://
pchampin: for the following reason
… for the first final report we need tidying up the intro and SPARQL ???
… propose to close this action
<pchampin> https://
<AndyS> For issue #121 : PR https://
pchampin: outstanding issue in the report was SPARQL comparison of RDF-star triples
AndyS: have made a draft
… which includes tests
… has good coverage
… including ordering of embedded triples
… because of the use case related to duplicates
… the defined ordering is somewhat arbitrary
<ora> arbitrary, but predictable, yes?
AndyS: other ways of ordering can be achieved by using the built-in functions
james: what about stable results?
AndyS: SPARQL order by has an extension point for unknow data types
… hence, not possible to define the ordering
… the extension will change the order
james: agree for unknow datatypes
… still useful to provide an order for everything that is known
AndyS: yes that would be useful
… happy to say that implementations should define the ordering
olaf: is this a general SPARQL issue?
james: it is broader
… but there is a SPARQL-star element to it
Action: AndyS: Add text on "good practice" to have a stable ordering.
pchampin: as mentioned by Andy, we don't have the right people in our group to address this
… may be added to tthe charter for he WG
Action: recorded: https://
<pchampin> https://
pchampin: next action is about example in the overview part
<pchampin> https://
pchampin: tidied up the intro
… split text into backgroun + history section and an overview section
… and added missing example about SPARQL-star Update
… already got some corrections by TallTed
… proposal to leave this PR open for a few workdays for people to comment
thomas: RDF/XML has an id attribute
… which is a shortcut notation to annotate a triple
… less verbose than RDF-star
… different perspective
… but shouldn't just say that RDF/XML has no solution to the problem that is the focus of RDF-star
pchampin: okay, that mention can be removed
… please propose a change in the PR
pchampin: #94 can be closed once the PR is merged
<R__Michael> sure!
<R__Michael> Hello folks!
Newcomers
pchampin: new person on the call (Michael Cary)
… unfortunately, sound problems
<R__Michael> My current role is chief architect at a company called IHS Markit. I'm overseing a new divison that is buiding some exciting stuff
<R__Michael> I've been passionate about the semantic web for some time, but very interested in participating and giving back to the community here.
<R__Michael> RDF* is a key requirement for this project and I'm honored to be able to listen in and provide value anywhere I can
<R__Michael> I also champion semantic concepts and developer conferences around the world
<R__Michael> We're likely using Stardog
<R__Michael> Actually just wrapped a call with them
<AndyS> https://
<R__Michael> I have a zoom pro account, happy to host at any time
<TallTed> "key requirement" suggests there's a Use Case and/or some Requirements that might be added to relevant doc(s)!
pchampin: maybe we can/should move to Zoom
… we could use the Zoom of Olaf's university
<R__Michael> wonderful :)
pchampin: Michael, please contribute a use case description
<R__Michael> Absolutely!
Back to open actions
pchampin: more on open actions ...
<pchampin> https://
<pchampin> https://
pchampin: #166 about a discussion on ref.opacity
… PR #173 includes such a discussion
… in this discussion, left the semantics as is
… i.e., ref.opaque
… because that's the least complex option to describe
… another thing that was added ...
… the other alternatives can be seen as smenatic extensions of the current solution
… TallTed proposed some corrections already
… will leave this PR open for some working days
… everyone, yell if you want things to be changed in that PR
AndyS: forgot to mention ...
… in section about SPARQL-star there were some issues about nesting
… changed the indentation in the sections
pchampin: seems to be a convention when using respec
AndyS: didn't seem to damage anything
<TallTed> respec ignores <h#> in place, makes it all work out *if* all the <section> are embedded/closed properly
AndyS: but the styling has changed
gkellogg: respec takes care of the rendering and of what ends up in the TOC
pchampin: another quick one ...
move to zoom?
pchampin: any opinions about moving to Zoom instead?
… it may work more smoothly
<pchampin> PROPOSAL: move away from BBC to Zoom?
<ora> I am also happy to host the group on Amazon Chime.
<gkellogg> +1
<pchampin> +0
<thomas> +0
<ora> +1
<AndyS> Zoom or Google Meet or Chime.
<AndyS> +1
<rivettp> +0
<william> +0
<james> +0
<olaf> +0
<TallTed> fewer steps to join zoom call than BBB ... and standalone app lowers burden on web browsers
<TallTed> +0.5
pchampin: so, generally a positive opinion
<R__Michael> +0 I've managed to make BBB work over LTE (will also work from home office, but not "office" office)
pchampin: I can set up something via the W3C account
Media types
pchampin: next item on the agenda is about media types
… we had discussions about this earlier
… but james wanted to add something
james: concern is that the spec should a more informed stance on the topic
… there is a lot of discussion in some github issue
… requirements for media types put constraints
… idea to do something more like what was done for the memento protocol
<pchampin> https://
james: profile header?
… in any case, as a reader of the report (not as implementer), a better founded discussion should be there
… the work would benefit from implementers taking a stance on the issue
… for example, the table suggested by ericp should be revisited
pchampin: I also would like the report to take a clearer stance on this issue
… but there was not one stance that felt like consensus by the group
james: okay, but the group has sufficient experience to include the discussion in the report
AndyS: a specific item in the discussion resulted in the inclusion of profiles
james: headers would be sufficient to address the cases
… as a reader, I would like to see the report mentioning it
pchampin: maybe that new document provide new info for the group to make progress on the issue
james: what it introduces is the notion that info should be included in out of band headers
gkellogg: it's broader
<TallTed> Profiles aren't a viable media type solution, because the media type to which such profiles would be applied must be a superset of those profiles (including no profile) -- which isn't so with any RDF-star serialization media type.
gkellogg: there is some consideration for when groups update their media types
<TallTed> It is fine to include things in the report on which we didn't achieve consensus, basically as "open questions", optimally including as much info as we have.
gkellogg: it is worth highlighting that a future WG should consider this issue
… we should not pre-decide for a potential WG
james: the report should not make an assessment
… but it should mention the alternative
pchampin: yes, agree that it should be mentioned
… also reluctant to write how it should be done
AndyS: if we are going to mention it, we need to mention that it changes the SPARQL protocol
pchampin: yes
<pchampin> PROPOSAL: add a ref to https://
<pchampin> +1
<gkellogg> +1
<AndyS> +0
<thomas> +1
<james> +1
<olaf> +0
<R__Michael> +1
<TallTed> +0 haven't read that one yet
<william> +0
<ora> +1
<rivettp> +1
Resolution: add a ref to https://
Action: pchampin to add ref to https://