Meeting minutes
Announcements and newcomers
<pchampin> https://
pchampin: I gave a presentation on Wednesday at the European data event forum.
… Not too much time for questions. Slides on the website.
Open actions
<pchampin> https://
pchampin: Ora's example was to mach a change to the arXiv paper on the seminal example.
olaf: Ora hadn't mentioned it.
pchampin: We discussed the common misconceptions of RDF-star should be avoided as much as possible as soon as possible in publications.
… Since people may come from reading that paper, they could come with poor expectations.
olaf: Something I can do is to put a statement into the PDF that refers to the output of this group.
… And that the arXiv document isn't up to date right now.
… Regarding the example, it might be tricky in that document to describe the problems.
pchampin: We have a section in the spec which describes the problem, so a paragraph that would reference people to our report would help.
… I'll assign #222 to Olaf.
pchampin: #64 and #3 were addressed by recent pull requests, so they could be closed.
Pending PRs
<pchampin> https://
AndyS: There are some minor editorial issues to get to.
… What I'm trying to do is not to be too prescriptive. People shouldn't be able to claim that a base RDF 1.1 system is RDF-star.
… It talks about systems that may read or write RDF-star in at least one form.
… SPARQL-star is easier, as there's a test suite.
olaf: I agree that it's easier for SPARQL-star than RDF-star.
… Regarding the syntaxes, maybe we can talk about reporting RDF-star as input or output.
… To say "supports RDF-star" may be over-broad.
AndyS: This was a heavyweight day of allowing things that only input to conform (or output only).
… For the rest, I'm not sure what else we can say other than observing input and output.
olaf: The question was not to talk about systems supporting RDF-star, but those that support it as input and separately as output.
pchampin: For me, olaf's proposal doesn't change the conformance classes, but renames them to something less "promising".
… What the independent classes don't cover is the ability to output one format given another.
AndyS: It doesn't say anything about preserving data in the system, and base RDF does not either.
AndyS: I didn't put anything in about semantics, as it isn't observable.
… I don't know of a semantics test of an RDF system.
pchampin: Somehow, the semantics suite captures a missing part between input and output.
… But, not all RDF systems have a way to check for simple entailment.
… I think adding the semantics test suite to the conformance section would be a problem.
pchampin: The 1.1 specs also just list it in the header, but the conformance section is quite general.
gkellogg: maybe some group would consider entailment regime tests for SPARQL.
pchampin: I agree, that might not help us finish out work.
olaf: This is now about the syntax tests, but explicitly requiring a system to pass at least one would rule out a system support JSON-LD-star only.
gkellogg: we should implicitly include other systems.
<pchampin> RDF 1.1 Concepts: "Implementations cannot directly conform to RDF 1.1 Concepts and Abstract Syntax, but can conform to such other specifications that normatively reference terms defined here."
pchampin: That's their way of not restricting to different serializations.
AndyS: RDF 1.1 concepts has no observable concrete syntaxes.
<pchampin> https://
pchampin: The idea was to put something into the introduction to reference important concepts elsewhere in the document.
… We noted people coming with some expectations which were wrong, and wanted to signal these early.
… I kept it short and just add pointers to in-depth discussions.
… But, it seemed important to add more about occurrences and added a new example.
… I think it is complementary to other examples and highlights different use cases.
<pchampin> https://
pchampin: This example is about a triple being added by different people, so it is a provenance use case.
… It's about the triple itself, but not about a statement itself.
<pchampin> https://
pchampin: The added example is about Liz Taylor marrying Richard Burton twice.
… I think the second example nicely complements the first one; it's not strictly provenance related, but can happen in other situations.
rivettp: My concern is that we're representing marriage as a resource, and a triple is rather fragile.
… How would it be describe with Richard Burton as the subject?
<fabio_vitali> I said that
pchampin: We need to be precise on if we're describing the wedding or the marriage.
… About representing either as resources, I agree. But this answers and expectation by people coming from the PG world about why it's interesting to have properties on edges and to have multiple edges.
rivettp: My concern is the reverse, normal RDF would a relationship and I'm not sure ...
pchampin: This doesn't describe the problem of inverting the subject.
… We're defining resources to describe the weddings, but the added value is that we still have an arc between the two.
… That arc could be inferred by OWL, for example.
… But somehow we have the best of both worlds.
rivettp: Independent of property direction, we don't describe inverse relationships.
AndyS: The graph database for Neo4J has a section an anti-patterns about annotating arcs.
… Even in the PG world, there is recognition that using the graph as a network graph doesn't always get you the patterns you want.
… The marriage example is different, as I think legally, these are separate marriages. In natural language we don't refine those details.
pchampin: I'm interested in the anti-pattern page.
… We should be carful to not try to support examples which are anti-patterns.
AndyS: If you're annotating a first-class thing in the graph ...
fabio_vitali: I would like to identify the conceptual item that makes my graph true.
… In this case that RDF-star identifies something about a triple that makes the graph true. It's about the triple and not the face.
… What makes me dubious is that the statement is about the marriage and not the statement. It should be about contextual information.
… Is it appropriate to use the "occurrence" keyword rather than trying to identify the truth of a statement based on the information around it.
pchampin: I think the two examples are at opposite ends of the spectrum of facts vs statements.
… I've felt that people using RDF-star needed all of these use cases.
… It goes in Andy's point about anti-patterns.
olaf: I don't have a problem with having the example. But, having it in this section may be misleading and cause more harm than good.
… As you notice, this example has some additional assumptions, namely that the occurrence property is transparent.
pchampin: It should be renamed to remove that false impression.
olaf: I see the section about the possibility of talking about occurrences of triples and not of the things the triple describe.
… There's a difference with the two examples in this regard.
pchampin: This discussion shows that it may bring more confusion than clarity, so I would be willing to remove the example.
<fabio_vitali> We could invent a different example dealing with triples rather than relationships
pchampin: My conclusion is that the new example probably does more harm than good.
… It is orthogonal to other things in the introduction.
olaf: Do we have any other example that speaks to PG peoples use cases?
… This question will keep coming up, so it would be good to have such an example.
… Even if it's not perfect, but to show that it is possible.
pchampin: Could this be done elsewhere, perhaps in a blog post? The example in the report may create too much confusion.
… We could agree to work on a series of blog posts that describes the relationship between PGs and RDF-star.
ora: I like the proposal too and would participate.
… For this report, I don't think we should rock the boat too much.
… Having a separate post might help prevent that.
pchampin: I'll remove the example from the PR.
Action: pchampin to remove the "Taylor-Burton" example from the PR
Publishing a final report
pchampin: We have a couple of other minor PRs. That's all we have left for PRs, and it would be nice to be able to publish at least another public draft if not a final report.
… I was expecting to have another call in two weeks unless people it's too close to Christmas.
<rivettp> 17th is fine for me
<ora> I can do 17th
<fabio_vitali> Just wondering if it makes sense to use the occurrence pattern as a way not only to count occurrences of the same triple in different datasets, but to evaluate different levels of confidence different people may have about the same statement
AndyS: How do we declare ourselves finished? (by publishing the report)
pchampin: We might still meet to discuss the charter or blog post, but after the final report we can claim success.
AndyS: Further issues can then point to the WG.
pchampin: So, we have two more weeks to iron up the pending PRs. Other than the example, it's mostly editorial.
<pchampin> PROPOSED: handle the remaining PRs until the next call (2021-12-17) and publish a final report then
<gkellogg> +
<pchampin> +1
<olaf> +1
<fabio_vitali> +1
<ora> +1
<AndyS> +1
ora: what do we do about remaining issues?
<fabio_vitali> I got to go. See you on the 17th
pchampin: These issues are explicitly things that are open discussions.
<pchampin> is:issue is:open -label:discussion -label:use-case -label:later
pchampin: I'll ping Peter on #220, but it could be labeled "discussion" as we're not likely to change anything now.