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://
pchampin: no pending actions on github
andys: checkup on the issue about the SPARQL-star grammar
<pchampin> https://
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://
<pchampin> https://
gkellogg: retrieving the service descr. is not part of the protocol
<james_> https://
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://
Action: pchampin to add a paragraph on SPARQL service description and sd:feature
<TallTed> https://
pchampin: good approach for the optimistic perspective regarding the mimetypes
<ora> Sorry I was late.
<TallTed> see also https://
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://
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://
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://
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