30 April 2021


AndyS, gatemezing, gkellogg, james_, olaf, ora, pchampin, TallTed, thomas

Meeting minutes

<AndyS> Hi

<pchampin> hi

<AndyS> "not knowing who has scribed, I nominate Ora"

Announcements and newcomers

pchampin: RDF-star will be presented at the KGC

Open actions

<pchampin> https://github.com/w3c/rdf-star/issues?q=is%3Aopen+is%3Aissue+label%3Aaction

pchampin: no pending actions on github

andys: checkup on the issue about the SPARQL-star grammar

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

pchampin: the grammar is not complete
… double-pointy brackets for expressions are missing

<AndyS> I've made it an "action" and assigned it to myself.

AndyS: wrapped up about organizing the manifests
… has been merged

PR 161: Media-types

pchampin: wrote a section based on discussion from last week
… including a listing of pros and cons of the different approaches
… and clarification that the group didn't reach consensus
… Hope that all arguments are captured

thomas: question: what ways are there to make explicit that an endpoint supports SPARQL-star?

pchampin: no answer

<TallTed> https://example.org/sparql-star :-)

gkellogg: it would be reasonable to add something for a SPARQL-star service description

<gatemezing> +1 to add a SPARQL service description

<james_> https://www.w3.org/TR/sparql11-service-description

<pchampin> https://www.w3.org/TR/sparql11-service-description/#sd-feature

gkellogg: retrieving the service descr. is not part of the protocol

<james_> https://www.w3.org/TR/sparql11-service-description/#sd-resultFormat

gkellogg: it's a machine-readable approach

<TallTed> It's not currently part of "every client's" activity; more part of advanced client's activity, when they're looking for a specific (typically more advanced) feature

pchampin: we may define an IRI for a SPARQL-star feature
… to be used in such service description
… and then encourage providers to include it in their service descr.

<james_> the "standard" features are described in the service description recommendation

AndyS: another use of the service descr. ...
… used by aggregators

<TallTed> more details, including example features -- https://www.w3.org/TR/sparql11-service-description/#sd-Feature

Action: pchampin to add a paragraph on SPARQL service description and sd:feature

<TallTed> https://www.w3.org/TR/sparql11-service-description/#sd-Language might be more appropriate, i.e., SPARQL-star is a different language than SPARQL 1.0 or SPARQL 1.1

pchampin: good approach for the optimistic perspective regarding the mimetypes

<ora> Sorry I was late.

<TallTed> see also https://www.w3.org/TR/sparql11-service-description/#lang-sparql10query and following

pchampin: my fear is that having an x-... mimetype may make people use it

gkellogg: that's orthogonal to the service descr. issue
… it's reasonable to have an RDF-star namespace

pchampin: will keep the PR on media types open for a few days
… so that everyone can take a look and react
… and if no complaints in a few days, then the PR will be merged

PR 162: Semantics

pchampin: made another PR about the semantics of RDF-star
… it's less disruptive than the previous one
… Two advantages:

first, get rid of hidden IRIs

second, it's consistent with SPARQL-star eval.semantics (at least, PA thinks so)

pchampin: doesn't change anything in the semantics-related test suites
… any opinions about it?

<Zakim> AndyS, you wanted to ask about simple literals

AndyS: talking about simple literals causes trouble
… they don't exist in RDF but only in the syntax

pchampin: that's right
… it was already in the previous version

<pchampin> https://w3c.github.io/rdf-star/cg-spec/editors_draft.html#mapping

pchampin: agree that they way it's phrased is ambiguous
… Peter suggested something else
… which is probably a better idea
… PR will be adapted accordingly
… Waiting for Dörthe and others to take a look
… if no complaints in a couple of days, then it will be merged
… only things it changes are things that none liked before

Open-ended discussions

AndyS: "How do we get out of this" question
… how do we get to a finished version?
… what time frame?
… shall we call the next draft the "last call"?

<TallTed> "time" isn't the best measurement. "the point where none of us see major issues" would be good.

AndyS: agrees to TallTed
… but there are no more major issues

TallTed: the point of this task force is to focus on a particular thing
… if we don't see no major issues with that thing, then
… the report should go to RDF-DEV CG

AndyS: The last call may go to RDF-DEV CG
… Is there a list of remaining major issues?

<gatemezing> We can tag here https://github.com/w3c/rdf-star/issues "mejor issues" ?

pchampin: tag issues in github

AndyS: tie that to the document

Action: create "outsanding issues" in the CG-report as being the things to complete before we're done

thomas: want to confirm that he is working on a longish email about the semantics
… wants to convince the group of moving to transparency semantics

gkellogg: in addition to an email, a PR would be great
… that PR should capture the alternative proposal

AndyS: instead of a PR (which freezes it), put it into a separate document

gkellogg: or on a wiki page

thomas: my aim is still to change it
… I would like to have a discussion first
… but, of course, prefer a note

pchampin: agrees that, at least, the rationale for the decision should be in the report
… regarding freezing: we can have both
… it's similar to the discussion of the seminal example
… it's good to have the report as the single-point of reference

TallTed: what#s nice here is that we are not an immutable academic paper
… we can make it a "snapshot draft"
… which may include pointers to the discussions in the github issues, the mailing list, etc

pchampin: agrees
… yet, it would be nicer for the reader of the report to have a summary in the report
… rather than just a link to somewhere else

thomas: yes

Action: add a section about the rationale for semantic opacity / transparency

TallTed: may even be marked as a "feature with risk"

AndyS: this can get out of control
… wouldn't have a report with a long discussion of the alternatives
… counterproductive opposite the Property Graphs community
… may seem as if nothing was agreed

pchampin: no, instead, intention is to give a rationale for the solution (semantics) that we keep in the end
… really only explain the consequences of the semantics

TallTed: didn't think the focus of this work was to convert PG people to the RDF world
… but instead to fill a perceived gap in RDF that might send people from RDF to PGs...

gkellogg: it provides a formal underpinning
… marketing

pchampin: to Ted: I think it works both ways

gkellogg: another thing that came up...
… difference between relationship and attributes in PGs
… there is a distinction that some people see when comparing commercial PGs and RDF triple stores

pchampin: see how it is related to the PG versus RDF discussion
… but not specific to RDF-star
… usually, we consider this a representation issue
… however, it may also be deeper

<gkellogg> Discussion is in EasierRDF https://github.com/w3c/EasierRDF/issues/45

pchampin: for instance, in Cypher the distinction is also in the query expressions
… perhaps out of scope

gkellogg: suggest to take a look at the issue in EasierRDF github
… and to chime in

AndyS: Actually, it is in OWL
… datatype properties versus object properties

pchampin: okay, OWL has this distinction
… but rarely any visual representations of RDF graphs
… that make this distinction
… e.g., by visualizing an RDF graph more in a PG-like manner

ora: comment on what Ted said earlier about the perceived gap between
… PG and RDF
… when talking to customers who are just starting
… they almost always ask whether they should go for RDF or PG
… and it seems to them that there is no going back
… RDF-star may help to narrow the gap

<gatemezing> Ora, that perception is not because you provide both PG and RDF in your tools?

AndyS: primarily about provenance of (RDF) data
… and being able to handle it in a convenient way

ora: to the question from the chat: it is not only about that
… not always the case
… instead, more general discussions about graphs

<gatemezing> Thanks ora! Makes sense

ora: even before a decision which type of DB to pick

pchampin: KGC next week, but no overlap with the call

<gatemezing> Bye!

<william> bye!

<ora> Bye

Summary of action items

  1. pchampin to add a paragraph on SPARQL service description and sd:feature
  2. create "outsanding issues" in the CG-report as being the things to complete before we're done
  3. add a section about the rationale for semantic opacity / transparency
Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).