<pchampin> Meeting: RDF*
<pchampin> Agenda: https://lists.w3.org/Archives/Public/public-rdf-star/2020Nov/0009.html
<pchampin> scribenick: rubensworks
pchampin: In the agenda we said to start with a round of introductions.
... I am an associate professor in Uni Lyon.
<Jerven> pchampin is associate professor in Lyon.
<Jerven> is currently on sabatical and helps olaf getting organized
pchampin: Currently in a sabattical. I proposed to Olaf to get things organized around RDF*.
<Jerven> already in a few working groups
pchampin: I was part of a few WGs, such as RDF 1.1, and JSON-LD 1.1.
<Jerven> Andy Seaborne, is involved in several standards.
AndyS: I am Andy Seaborne, involved in several RDF standard.
<Jerven> Trying to understand usecases and long term benefit
<Jerven> Sorry for also scribing, hope it helps
AndyS: Not with a specific technical agenda. One interest I have is how to make the tech acceptable, so we can deploy it.
Pavel_Klinov: I am an engineer at Stardog. Focus on query evaluation in RDF, and was involved in the RDF* implementation.
james: I am with Datagraph/Dydra, a ... and SPARQL service. I'm here for the use cases. I hope to not only focus on the open-source world, but also our implementation.
Jerven: I work on uniprot at university of ?. I want to implement RDF* in Python and ?. My main focus is compact in ecosystem.
<Pavel_Klinov> Sorry, will try to speak louder, the mic settings seem ok
Pete Rivett: I work for Agnos AI. We build business solution around KG technology. I'm very much a user, and interested in acceptability and consistency among different platforms.
<Jerven> Jerven <- I work at the SIB Swiss Institute of Bioinformatics. I work on providing data in RDF such as UniProt, Rhea and Swisslipids. I worked on implementing rdf* in Python rdflib, and my worry is comatiablity in the ecosyttem
Peter Patel-Schneider: I work for PARC (Palo Alto Research Center)(?) (part of Xerox). I hope this will all turn out well. Interested in whether RDF* is just a surface syntax, or if it needs something new, and if this is reasonable to provide.
<pchampin> scribenicks: pchampin
<pchampin> rubensworks: researcher at Gent Univesity (Belgium). Focusing on decentralized query execution. RDF
<pchampin> ... Interested in RDF* and SPARQL*, and its impact on the research world
<rubenswork> scribenick: rubensworks
Thomas Lortsch: Student at Hagen(?) in Germany. Focusing on data modeling techniques. Observer for RDF*. My concern is that the scope is ?. I want to know how it fits together with other annotation approaches.
<pchampin> https://github.com/w3c/rdf-star/issues/15
pchampin: Olaf already gave his position in this issue, so I can talk for him on that.
... Goal is to make something that looks like a standard.
... As a CG, we don't have the power to make a REC. But we can draft one with the goal for a future WG.
... Via this way, we can move things faster than discussing things on the mailinglist.
... Side-note, adding yourself to the speaking queue is done by typing 'q+' in IRC.
AndyS: I raised this issue here because there are alternatives. We could have a draft spec, or an overview of the possibilities. W3C would benefit to have a solid spec from a CG. This would allow implementations to start early in the community.
pchampin: Agree, since implementations already started, we need a draft spec to avoid divergence.
pfps: I want to vote to go for one solution instead of several. This avoids people having to implement other options and later on change things.
AndyS: I have the feeling we want to get to tech work asap. Before we can do this, we need a consensus on the approach. For this, we need to have an overview of the use cases.
... Use cases such as providence, waiting for links, ... I am interested to hear what people are using RDF* for.
<pchampin> https://github.com/w3c/EasierRDF/blob/master/RDFstar/RDFStarUCandRequirements.html
pchampin: There was a document started with use cases, but it doesn't seem complete.
AndyS: I will make an issue and send a mail to collect them in there.
<AndyS> ACTION: AndyS: Open issue for UC&R, email list to highlight and invite UCs
pchampin: We have to make sure the use cases are recorded somewhere. Still, the current report aims to become something like a spec. There are impls, and we don't want everyone to go in their preferred direction.
<pchampin> PROPOSED: close issue #15, the current report should be a single proposal
+1
<Jerven> +1
<pchampin> +1
<pfps> +1
<AndyS> +1
<rat10> +1
<rivettp> +1
<Pavel_Klinov> +1
<james> +1
RESOLUTION: close issue #15, the current report should be a single proposal
<pfps> I don't think it is *necessary* to capture all potential use cases.
pchampin: Someone mentioned opening the wiki on GH. We don't have to create a deliverable, so the wiki might be a good medium.
<pfps> ... or even all actual use cases.
pfps: If you are obligated to capture all potential use cases, then you'll have something very complicated, which may not be what we want. So we have to define what types of use cases we want to capture.
pchampin: Agreed, not all use cases need to be handled by the spec, we just need to have discussed/seen them.
<pfps> Several use cases I've seen appear to need a mulit-modal logic, which, in my view, is out of scope for RDF*.
<rat10> use cases could be a good way to clear what RDF* is and what it isn't
<rat10> or doesn't want to be
<AndyS> and we don't have to solve all UC. What it isn't is v important.
<pchampin> https://github.com/w3c/rdf-star/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted
pchampin: I've tagged several issues with the tag help-wanted.
... There are three of them.
... They could be implemented in a PR.
https://github.com/w3c/rdf-star/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22
<pchampin> https://github.com/w3c/rdf-star/labels/help%20wanted
<Jerven> Did my sound go or is everyone quiet?
pchampin: Two of them were proposed by Jeen, who could not join today.
... These are about result set in JSON and XML as response by SPARQL endpoints. They are implemented in different variants already, so we need to do this to avoid heterogeneity.
<Jerven> Sorry missed a bit, as sound stoped working.
pfps: I'm not sure if it's clear this is actually needed.
<pchampin> SELECT * { ?x :createdBy :alice }
pfps: If RDF* is a shorthand for some form of RDF, then output could just be RDF, like before.
AndyS: If RDF* is just syntax, then we wouldn't need to do anything.
pfps: Indeed, not saying this is a good idea. We just need to determine this first.
... It's fine if someone is willing to do the work, just as long as we're clear there is a chance this may not end up in the original report, otherwise people may get annoyed.
pchampin: You're right. The next issue about referential transparency will determine whether or not RDF* is just syntax.
... I don't fully agree, for example in the case of my query above. In this case, ?x can be an embedded triple, and it would be desired that the full triple would be returned.
<rivettp> could you not have a syntactic sugar for the results also? As an option
pfps: SPARQL output formats are pretty canonical. So doing "something extra" sounds very ... for clients that understand.
pchampin: Some clients do indeed understand the returned triple format.
... So perhaps this issue is not trivial indeed.
<pfps> The issue is that consumers of SPARQL output need to be able to understand this "enhanced" output. Right now this is fairly simple, and making it non-simple is not a good idea.
AndyS: pfps: how should we proceed then?
pfps: As a first step, we need to figure out what RDF* is. Only then can we define what SPARQL* is.
... Someone can independently to produce a report for SPARQL*, but it should not be final yet, because it may become irrelevant.
pchampin: In order to determine what RDF* is, we have to wait until people give use feedback on use cases.
... I propose to discuss the referential opacity issue.
<pchampin> https://github.com/w3c/rdf-star/issues/22
pchampin: This is about one of the most challenging parts of the current spec. This is what prevents us from standard reification as an underlying model for RDF*. Reification is not referentially opaque, i.e., they talk about the statement, not the things in the statements.
<pfps> Here is where the multi-modal logic creeps in. Someone is going to have to very carefully delimit what is supposed to happen and what can be done.
pchampin: If Lois believes supermand can fly. If we believe Superman==Clark kent, we should not believe Clark Kent can fly. (scribe: I hope I wrote this down right...)
james: I vote -1
<pfps> A better example is < susan says << john height 6.0 >> > vs < susan says << john height 6.00 >> >
Jerven: I didn't have the feeling that without sameAs reasoning, the problem doesn't disappear. I was wondering if this wasn't a problem. sameAs isn't the source of the problem, but multiple people may say things about the same things.
pchampin: Problem is about the fact that two IRIs may reference the same thing, owl:sameAs is the easiest way to do this. Same thing can happen with literals, so you don't need owl for that, just datatype-aware inference.
... We are not interested in the referent of the terms, just the terms themselves.
<rivettp> what if we have lois believes Superman owl:sameAs ClarkKent?
Jerven: What is missing, if you put the same problem, but put ClarkKent everywhere, then you still have the same problem.
... I don't have the feeling the proposed solution solves the problem we're having. I will write it down in an email, because this is hard via a call.
<pfps> the problem here is that RDF is not a modal logic. Using it for that purpose is not going to work.
pfps: There are lots of cases where you can say things in RDF and RDF* that look nice. Anything that assumes there being a there there, is not correct. There is not modal reasoning in RDF. If you want to solve this, go to N3.
<pfps> Not that I'm recommending going to N3.
pchampin: I understand that the belief thing may lead to modal logic, but I'm not asking RDF* to be modal logic.
... Provenance is a use case that is less slippery.
... It may benefit from ref opacity as well.
... We may be interested in not only what was said, but also how it was said.
pfps: Trouble is that now, provenance has a different kind of problem.
... Every act of asserting prov is an interpreation of what happened. It is not about what actually happened. To see this, go to any political situation.
<pfps> I agree that provenance is *less* slippery, but it is not completely non-slippery.
pchampin: Isn't this an argument to not overinterpret those prov annotated triples?
pfps: Problem there is not overinterpretation, but actually getting the tokens correct.
<Jerven> \q?
rat10: I'm not decided on what's best. There have been long discussions on that the interpretation of named graphs.
... If you want to be faithful, you use a datatype string for what you want to annotate, but you can't sparql that, and can't have bnodes.
Pavel_Klinov: I'm missing in this discussion, whether this depends on SA/PG mode.
<pfps> I don't see that assertion changes an opaque semantics to a transparent one.
pchampin: I'm not sure. This feels orthogonal to me.
<pfps> And here we are again with multi-modal reasoning.
Jerven: If you run OWL inference, you want to run it. You *do* say these explicit things. Sometimes you may not want to run it.
pchampin: I disagree that this would be a requirement for OWL reasoning.
... We won't solve this today.
... I did some experiments, and most systems I tested have ref opacity at the moment.
<pchampin> and thanks to ruben for scribing!
<AndyS> pchampin - I just did a PR to copy the UC&R doc from EasierRDF so it wil be (if I got it oight) visible as ... HTML appearance, not HTML tags.
<pchampin> @AndyS good idea, thx
<AndyS> https://github.com/w3c/rdf-star/issues/29
<AndyS> UC&R issue