W3C

RDF-star

21 May 2021

Attendees

Present
AndyS, gkellogg, james, olaf, ora, pchampin, rivettp, TallTed, thomas
Regrets
-
Chair
pchampin
Scribe
olaf

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://github.com/w3c/rdf-star/issues?q=is%3Aopen+is%3Aissue+label%3Aaction

pchampin: open actions on me
… still late on the charter for a possible WG

<pchampin> https://github.com/w3c/rdf-star/issues/164

pchampin: another open one is about SPARQL service description
… not addressed yet

<pchampin> https://github.com/w3c/rdf-star/issues/165

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://github.com/w3c/rdf-star/issues/121

<AndyS> For issue #121 : PR https://github.com/w3c/rdf-star/pull/172 Currently "draft" - Direction complete. Presentation and HTML needs attention. Includes tests.

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://github.com/w3c/rdf-star/pull/172#issuecomment-846030677

<pchampin> https://github.com/w3c/rdf-star/issues/94

pchampin: next action is about example in the overview part

<pchampin> https://github.com/w3c/rdf-star/pull/171

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://ihsmarkit.com/

<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://github.com/w3c/rdf-star/issues/166

<pchampin> https://github.com/w3c/rdf-star/pull/173

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://www.w3.org/TR/dx-prof-conneg/

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://www.w3.org/TR/dx-prof-conneg/ in the section on media-types

<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://www.w3.org/TR/dx-prof-conneg/ in the section on media-types

Action: pchampin to add ref to https://www.w3.org/TR/dx-prof-conneg/ (with warning about SPARQL protocol)

Summary of action items

  1. AndyS: Add text on "good practice" to have a stable ordering.
  2. recorded: https://github.com/w3c/rdf-star/pull/172#issuecomment-846030677
  3. pchampin to add ref to https://www.w3.org/TR/dx-prof-conneg/ (with warning about SPARQL protocol)

Summary of resolutions

  1. add a ref to https://www.w3.org/TR/dx-prof-conneg/ in the section on media-types
Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).