Meeting minutes
<TallTed> pchampin -- does RDF&SPARQL meeting span midnight? (RRSAgent should be informed.)
ktk: I suggest we start with a round of introduction, then ora and I will present where the WG is at the moment
Ugur: I work for Depixen (based in London), we want to use RDF in our knowledge graph; new to this WG, trying to figure out how to contribute
csarven: I'm an independent IE, member of the TAG
… I'm here to make sure the WG is aware of architectural constraints
piotr: I founded the company Neverblink, we work with streaming RDF, we develop the format JellyRDF
… also active in the CG for RDF streams processing
Youngmin: I work at KETI. We work in intelligent buildings, we use ontologies to make AI understand buildings.
… I'm interested in the status of RDF & SPARQL
Enrico: member of the WG, co-editor of RDF Semantics.
… Recently more interested in the link between knowledge and data.
Brent Zundel: here on behalf of the AB. I'm here to pick your brain about the W3C process.
pchampin: I'm the W3C staff contact of the WG.
TallTed: I'm with OpenLink, we make Virtuoso. I'm fixing grammar in all your PRs.
ora: I'm the co-chair of the WG, currently working at AWS, member of the Neptune graph DB group.
… I was a co-editor of the very first RDF spec.
… Also co-author of the original Semantic Web vision, and contributor to many early SemWeb WGs.
ktk: I'm the other co-chair of the WG, I run Zazuko.
… Also working with Hanna Bast on Qlever.
message from the Advisory Board
[Brent is presenting the Process improvement task of the AB]
<TallTed> co-chair of WG, not of TAG, correct?
status of the WG
<ora> https://
Slideset: https://
ora: ktk and I presented those slides at the Knowledge Graph conference last May in New York
ora: RDF is a widely used knowledge description language
… half of all the pages in the common crawl dataset contain some embedded RDF in them
ora: the timeline of RDF is very long
… in 1997, timbl came into my office, asking what was wrong about the web
… I answered that I wanted to build agents for the web
… RDF schema was pretty complete in 1999 but waited until 2004 to become a recommendation
… the last item in the slide was a bit optimistic...
… one reason for the delay was that we decided to have all the discussions up-front before going to REC
… now we are confident that we have considered most of the important questions
ora: the motivation was to deal with "statements about statements"
… from the very beginning, RDF had a reification mechanism
ora: different options to talk about a statement: standard reification, or custom "lifting"
ktk: many people working with RDF were quite comfortable with the custom "lifting", so the standard reification was not that used
… and most people complaining about it were people from other communities (e.g. LPG)
ora: RDF graphs are mathematical sets, a triple can be only once in a graph
… changing this would break RDF 1.1 semantics
… there were discussions about using named graphs, but named graphs have been used for all kinds of purposes ("“semantics by convention”")
… we didn't want to hijack named graphs for just one purpose
… this was a good thing, but also problematic because we need to explain a lot why we did
ora: triple-term can be thought of as a representation of a triple as a node
… they are not unlike literals
… then we can associate them with an identifier ("reifier") via the new property rdf:reifies
… we can have any number of reifiers for a given triple
… which solves the multiple-marriages problem
… a reifier can also be associated to multiple triple terms
… this was a very controversial issue in the WG, for various reasons
… one of them is that they become very similar to named graphs
… also this structure has no counterpart in LPGs
… nevertheless, the consensus was to allow this
ora: the rdf:dirLangString datatype is for literals with a language tag *and* a base direction
pchampin: note that in the meantime, we also covered RDF/XML, which is now also able to express triple-terms
ora: reifiers, not triple terms, can be used in the subject position
… a reason for this constraint on triple term was to avoid people using the triple term when what they actually needed was a reifier
… also we felt it was easier to add that possibility later on rather than removing it
ora: it will be interesting to see what the LPG community will do next
… they are becoming aware that RDF is a force they need to consider, rather than compete with
… I will leave ktk answer question
ktk: for those who want to use it, Jena is already implementing it (as an experimental feature)
ora: success will be measured by adoption, which needs implementation
Enrico: it is worthwhile to mention that last week we had another tutorial at ISWC about RDF 1.2
https://
it ran on a full half-day, so it complements that presentation well
ora: how was it received?
Enrico: very well, a lot of technical and philosophical questions
ora: we had to take into account 25 years of RDF implementations
pchampin: another implementation that already implements RDF 1.2 is Oxigraph
ora: one point that I think we need to discuss when RDF 1.2 is how to use these new features in practice
… we will need dedicated vocabularies
… I believe that those mechanisms are particularly useful for cross-cutting domains, such as provenance
pchampin: I would not recommend to use triple-terms for modelling marriages, in fact
… but it is useful to integrate data that model marriages as nodes and other data that model them as edges
ktk: somebody made a good point last week at ISWC about "unit testing with SPARQL"
… how easy it is to SPARQL your model is a good quality criterion
Enrico: this touches an important topic that we have not discussed yet
… there are many different ways the same information can be represented
… although RDF is too weak to express that two constructs are the same
… this questions are a huge can of worm, that propably should be tackled with a higher level language
csarven: I'm interested in what RDF / SPARQL 1.2 would bring to implementers
… now you can use this syntactic sugar to add more information to a triple
… in the current state, we don't have that view as strongly
… I'm wondering how people would be relooking at their own datasets
… did you reflect on this?
ktk: we did, to some extent.
… We are waiting to see how people explore the new features in ways that may become common design patterns.
… Also we are RDF geeks who write Turtle by hand, so the syntactic sugar matters to us, but end-users rarely do. This will be hidden to them.
csarven: you have good use-cases, e.g. provenance.
… I totally agree that the UI will also make a difference.
Enrico: we also have to be clear that there are two different classes of use-cases.
… One is the marriage, which should in fact be done otherwise.
… The other one is provenance, where the triple-term is actually required.
ktk: thanks, let's break
<ktk> ora: we would be ready
revising the basic encoding algorithm
pchampin: I had this topic in my mind for a while.
… It's about RDF Interoperability note
… RDF 1.2 has two level of compliance: basic and full
… basic is everything in RDF 1.2 except triple terms
… it makes it more complex so that way it can be implemented without.
… To prevent fragmentation, we want to provide some non-normative guidance
… about how basic and full could be interoperable.
… One way is very close to classic RDF reification.
… but we use rdf:TripleTerm instead.
… Like this we could reconstruct the RDF graph and it's entailment preserving.
… It is a purely syntactic encoding.
… There are 3 design goals: Information preserving, idempotent, universal
… For the moment, it is not entierly universal. It will refuse any graph that is hybrid, which means partially encoded and partially not.
… If you merge them, it cannot be encoded. In retrospect I am not entirely happy with that.
… I would like to have the caveat on information preserving instead.
… If part of the graph is already encoded, the part that is still triple terms would be encoded.
… It is not information encoded that way but fully universal. So we would not have to be careful about merging.
… I don't care if we are not able to re-construct a graph that was partially encoded and partially not. I don't think this is very interesting to reconstruct.
… But the benefit is that people would not have to be careful about merging, which I think is more useful.
Enrico: I understand it. But my first reaction is I do not like it.
… we would have to be careful with encoding. Because we don't want to have two blank nodes describing the same triple term. So now I need additionally to mint the blank node to check if the same blank node is not used to describe another triple term.
… You simply have to redefine the notion of merging.
pchampin: Thanks, I am quite convinced that my proposal is then a bad idea.
… Good news is I don't have to make changes to the document then.
… We cannot write it down but semantically it exists.
Enrico: simple example: John loves Marry. There is a denotation of Mary could be the denotation of triple term in itself.
… in RDF this never was a problem. But the moment we enrich RDF for example with sameAs, we can write a triple term that says "John loves Mary/gi" sameAs Marry
… Now marry is a proposition. And John loves a proposition. That does not go along with the intended meaning.
… If we leave the semantics as it is in RDF and RDFS, then we are good.
… A future OWL might have that problem, they need to be careful.
… We should say that the definition of Triple Terms need to be well founded.
Enrico: This could be a box in the Semantics document. I'll make a PR
… Then we finally agreed with Doerthe to close the last PR, we should be ready for CR.
Status of SPARQL
ktk: we had to wait until things were stabilized in RDF until SPARQL could move forward
… but now that it's the case, things are moving forward
pchampin: the CWG of RDF Star already prepared a lot of work for SPARQL as well. There are some new functions like is triple term etc.
… There are also functions related to base directions
… it's a new kind of literal required for i18n
… Some things still under discussion is ordering.
… Then there was a question of whether < or > should be defined on triple terms. Apparently the SPARQL TF is discussing that.
… But in general the bulk of the work was done in the CWG.
Piotr: At which point should we start implementing RDF 1.2?
pchampin: From our group PoV the RDF specs are now stable. But it is not through yet in the process.
Piotr: Does the WG have a migration path from RDF Star to RDF 1.2 in mind?
pchampin: The data model has not much changed. The big changes are in the surface syntax.
… The good news is that if it was valid Turtle Star it's still valid Turtle 1.2.
TallTed: We can't give you much about how to migration from a random version of RDF Star to RDF 1.2
ktk: if you would export it to Turtle and re-import it, you would be good?
pchampin: If you use the same Turtle file and the same SPARQL query, I would suspect you get the same results. There might be some corner cases.
Kazue: We are trying to use SPARQL to search through verifiable credentials. I want to prove that I've graduated at some University. And this University is located in that City. And that city has this population. So that should all be verifiable credentials.
Kazue: Verifiable statements are statements, that are represented in RDF. And they can be signed by someone, called Issuer.
… I can say that someone is a graduate of Kobe university. And it is signed by the University.
pchampin: At the moment verifiable credentials are using named graphs, in JSON-LD.
… Someone at ISWC said we have a problem with it, when we merge it, all the claims get merged to the default graph and the verifications are in the named graphs.
… How do you cope with this.
Kazue: We are not merging them into one graph, we keep it as a JSON-LD tree.
<Kazue> https://
<Kazue> https://
<ktk> s/Slideset:/Slide set:/
<ktk> s/Verifyable/Verifiable/
<ktk> s/verifyable/verifiable/