Meeting minutes
ora: Did Niklas say he cannot attend?
ktk: Only one regrets, from AZ
TallTed: nd Domenik
Several options to consider
ora: Niklas not here. We could have used some more explanation of his stuff.
… We can still have some discussion, but we time box it.
… At the end of this meeting we should have an understanding of which proposal we continue with
… for this WG! Other things may be taken up later.
… The ideas that have been discussed can be developed further after the WG.
… I like pfps' characterization
… and should be the guideline for our discussion
… According to pchampin the classical reification proposal cannot be developed.
pchampin: We did have a discussion. One proposal was that the double pointy brackets are just syntactic sugar for standard reification.
… My problem with this proposal is that it is different form how RDF-star has been implemented.
<pfps> I'm not following this argument at all.
pchampin: In particular, with simple entailment in SPARQL, all of a sudden it is not anymore purely pattern matching.
… Example would be a query including WHERE { ... ?t rdf:subject ?s ... }
enrico: Not sure I fully follow
… I am against using << ... >> as syntactic sugar for standard reification
… because it would lead to a mess
<Zakim> gkellogg, you wanted to sugggest that existing implementations of the CG version of the spec should not constrain what this group does.
gkellogg: reaction to pchampin, I have implemented RDF-star as an experimental feature
… the group should not be bound to what/how has the CG proposal been implemented
<tl> +1 to gkellog
ora: Yes, we should not be constrained by the CG proposal
pchampin: to gkellog, right, we are not bound by what was done in the CG
<TallTed> +1 to gkelloggg. Implementations of experimental, draft, CG, etc. non-WG specs should absolutely not restrict our output (though it *might* match in the end)
pchampin: My point was ... (?)
<pfps> RDF* can only be a guide. It cannot be something that is inviolate.
pchampin: my other point is that we might be strongly changing what people are expecting of RDF-star
… some people are expecting some form of continuity
<tl> and some fear it
TallTed: people should have no expectation of RDF-star
… RDF-star doesn't exist
… It was a draft proposal which had immense problems
<pfps> +1 to what TallTed is saying
TallTed: then it was input to a CG report
… Yet it is not a bound
<fsasaki> -1 to what TallTed is saying, uptake by implementers is an important piece of data
TallTed: It may be a negative example (if someone failed to implement it, it would be a sign that it is not useful)
ora: I agree
… Devils advocate question, Do we risk the community being split if ...
… There may be people who like the CG report and will go ahead using it even if not in the REC docs
tl: There are people who hate RDF-star
… What topics do you want to discuss?
… I want to know when I can respond to which topic.
ora: There was the email from pfps with the different characteristics
… I would like to use these characteristics as guidance
tl: No, I don't like Peter's categorization (as I explained per mail already). But just proceed.
fasaki: Regarding the community split
… Remember XHTML?
… There was such a split too.
… Also, we already have a split, think Property Graphs
… and vector DBs
… What we are discussing may seem from a different world to these people (LPG community)
<Zakim> TallTed, you wanted to ask whether those implementers/organizations are participating in this WG ... as that is how to properly impact our work
TallTed: Proper way to make ones preferences know about our output is to join the WG
… Indeed, the community split already exists
… Some companies went ahead to implement LPGs for which no standard exists
… Standards are important for interoperability
… For instance, you can dump your RDB from, say, Oracle and load it in MySQL, Postgres, etc
… Standards are important
ktk: Thanks TallTed!
… You covered my feelings very well.
<pfps> I note that there is an emerging ISO standard for property graphs and a property graph query language.
ktk: I'm interesting in making LPG obsolete by making RDF such that it can cover what LPG does
… We should really focus on making RDF better.
… To tl, your comments are at leats passive agressive. Stop doing that.
ora: I like hearing these strong words in favor of standards
… yet, that only works if we produce something
… So, let's get a spec out of the door.
<tl> adrian, i reject that. there are people who DO hate RDF-star
ora: Since W3C works based on consesus
<fsasaki> [just to clarify: I meant "the danger of community splits is a piece of data for deciding about how fast to move forward", not that we should do what the LPG community is doing.]
ora: So we have to answer question what we can live with
tl: There are really people who hate RDF-star (including myself). It is important to say that.
… Sometimes you are reading my emails the wrong way.
AndyS: We need to anchor something minimal to move forward.
… Guiding principle should be that we do not interfere with what can be added on top in the future
… I think the community expects us to deliver something that allows people to put properties on edges.
pchampin: On list of choices listed by pfps ...
… (concrete synatx, abstract syntax, semantics), I think it makes more sense to start on the abstract syntax rather than then concrete syntax
<pfps> +1 to the notion that one desired output of the group is the ability to associate edges with extra information
<ora> https://
pchampin: regarding statements about statements, I think a good start would be to try to be able to do this based on what is in the abstract syntax of RDF 1.1
ora: Let's have a concrete discussion about these four things that pfps has identified
… and what people can and cannot live with
Souri: I agree we need to focus on what is the minimum
<TallTed> pfps identified a 4x4x4 matrix of 64, not 4, things/options/proposals
Souri: yet, talking to LPG people, edge properties are important and must be in the new version of RDF that we come out with
… but we should also add support for multi edges
… because these are important in the industry
… and without them, we are not reaching what LPGs have
<tl> +1 to Souri
pfps: I had at least 64 ways to combine the case
<TallTed> 4 syntax x 4 concepts x 4 semantics = 64 combinations
pfps: I was trying to mention what decisions need to be made
… multiedges should be tere too
<TallTed> x however many multiplicity options = more combinations
gtw: I agree with Souri that multi-edge support is important, but it may be too big now
<Tpt> +1 to gtw
gtw: So what we do now should not block to add multi-edge support in the future
Souri: If people are using it in a certain way, they cannot break that
… important example are Named Graphs
… which have been used in various ways.
… My proposal supports multi edges, and I tried to make it as close as possible to the RDF-star proposal
… multi edges are so important for us at Oracle that we will do it in any case
… and we cannot wait for another WG
niklasl: In RDF there can be multiple occurences, which is a way to capture multi edges
<TallTed> is there a simple definition of "multi edge"? I gather it's not "multiple edges from a specific node" or "multiple edges between two specific nodes"
<Zakim> pchampin, you wanted to ask if any of our Use Cases pointing to the need for multi-edge?
niklasl: Would such occurrences be sufficient towards covering multi edge support?
pchampin: Do we have use cases that clearly point to the need for multi edge?
… I am not convinced of the usefulness of multi edges.
… If we don't have such use cases, then such use cases should be added (e.g., by Souri)
Souri: Example about a US president who had two separate terms
… other use cases would be where two people were married twice.
<Tpt> The Wikidata usecase: w3c/
<gb> Issue 24 RDF-star for Wikibase/Wikidata (by Tpt) [use case]
Souri: There was a Youtube video by Jesus Barassa (Neo4j) with an example about John lovel Marry three times.
<pchampin> I'm not asking for a complicated use-case, but something we can refer to in our UC list
Souri: Our Property Graph people in Oracle frequently have cases with multi edges
… It is important that the RDF standard can cover what LPGs can
ora: We (Neptune) submitted use cases to the CG and, as far as I recall, there was a multi edge use cases.
… We also had something in our OneGraph vision paper.
<TallTed> so "multi edge" approximately means "keep multiple occurrences of the same triple"?
ora: Maybe, Souri, the two of us can work out a proper use case.
<pchampin> I stand corrected, then.
pfps: Many of the use cases can be captured with multi edges
… But it is a fundamental assumption of RDF that there is only one triple with the same subject, predicate, and object
tl: But tokens work
… For instance, standard reification is about tokens
… In Nested Graphs we only talk about tokens
enrico: There is a major misunderstand regarding RDF versus LPG
… What matters in an LPG is where the labels and/or properties are drawn
… These are separate edges
… These edges are distinct, with a different identity, even if they have the same label.
… That's different in RDF because here a graph is a set of triples
… We should not confuse labels with identification of edges.
AndyS: I don't think the word "edge" means the same in RDF and in LPG
… We want to have multiple independent annotations of a statement/triple
Souri: Indeed in LPGs edges have an ID, but these IDs are not directly accessible to users
… to pfps, yes there need to be named triples
<pfps> Huh? The label in property graphs can be anything. It doesn't have to map to the predicate of a triple.
Souri: my proposal is completely backwards compatible
… that is, if you don't care about triple names, you don't need to use them and have RDF 1.1
… I want to add the option of explicit naming
niklasl: pfps is very right
… in RDF semantics there aren't multiple edges with the same s, p, and o
<pfps> triple uniqueness in RDF is not just semantics but also syntax and implementations, and SPARQL
niklasl: so, a triple is a type and, so, I understand the focus on types in the proposals
… However, if we have named graphs, then we have occurrences
… The context the a Named Graph potentially introduces gives that
tl: Remind everyone of the singleton properties proposal
… the semantics of that is pretty clear and it doesn't break anything
<pfps> How does SPARQL interact with singleton properties
ora: I would now like to move to a discussion of ...
… what are the things that people really want
… We had good arguments about getting things done in a way that more can be added later
… pfps' argument that RDF is about *sets* of triples and changing that would break a lot of things, including implementations
<pfps> As Souri said, however, moving to multi-graphs can be done in a compatible manner - the pain is (essentially) all on the implementation side
souri: Stardog may have had a use case for multiple edges
souri: multi edges can be done in a compatible way
ora: are you saying that SPO is unique and SPOI is also unique
souri: yes
and this is (potentially) different from labelled property graphs
souri: if you don't use statement names then everything is still the same
<niklasl> +1, those are quads, with a specific meaning for the 4th
TallTed: this is the same as named graphs in RDF 1.1 so this is already in RDF
AndyS: the proposals tend to have multiple parts so it is hard to pull out what is going on
AndyS: and some proposals say they don't change anything but then list changes (to SPARQL)
AndyS: hence we have to do something simple
souri: multi edge support doesn't change anything
AndyS: except if asserted triples is turned on
souri: the default behaviour ends up with nothing changing
AndyS: are you open to also occurences and types?
AndyS: syntax may not change but internals have to
souri: syntax is the most visible part
souri: I view named graphs as way to do multi edge but people use named graphs in a different way that would be broken if named graphs were used for multi edge
souri: that's why an extra component is needed for named triples
niklasl: there is no definition for the fourth component of a quad and it is being used in different ways
niklasl: we could use some names only and thus not break every use of named graphs
pchampin: I think we should be careful about using existing abstract syntax in unusual ways
<ktk> (sorry had power cut)
pchampin: for example singleton properties cause performance difficulties in implementations
pchampin: what happens when two graphs are merged - do triples from the two graphs end up being different?
tl: every proposal will require some change - either syntax or use
tl: .. or implementation (for example singleton properties require a index on predicates)
tl: what requires lots of implementation is a new term
<niklasl> +1 for modelling (based on use cases)
tl: I'm interested in making things easy for users
souri: I'm not bothered about implementation
souri: I'm bothered about changes required by users
souri: merging is a problem in any case - one has to be very careful
Tpt: I see a lot of people using named graphs and other saying we can't use named graphs
Tpt: who can live with which way?
Tpt: lots of implementations provide union of graphs
AndyS: it is also common to use named graphs for data management
AndyS: my experience is that adding a new term is less code than changing underlying assumptions in SPARQL
gkellogg: we keep coming back to named graphs, with plusses and minuses
gkellogg: can we make statements about graph names that allow us to treat them in particular ways
gkellogg: as there is pushback on adding syntax then this might be a way forward
<niklasl> +1 for that option
ora: if we went this way then the default would be to treat named graphs as they currently are
<tl> the nested named graph proposal describes a way to do that
<tl> leavingh other uses untouched
gkellogg: new syntax would expand into statements that supported the use for the syntax
<tl> pfps: anyone can say anything about anything
niklasl: that's the way I want to go - with syntactic sugar to help
niklasl: in systems like BlazeGraph that assume union graph semantics special efforts have to be used
niklasl: I think we are close to achieving RDFn with named graphs
adrian: I get the impression that we have 3 or 4 ways to look at things
adrian: I'm on the triples side - I rarely use named graphs
adrian: I don't want current things to break
adrian: the named triples side doesn't break things
adrian: the named graphs side makes me worry about things breaking
adrian: labelled property graphs side only cares about capturing labelled property graphs
souri: I consider your proposal close to RDFn
<gkellogg> Blank nodes are commonly used as graph names in specs using JSON-LD.
souri: ... examples of named graphs with triples in them ...
souri: what is the status of blank names for graphs
souri: my problem has to do with merging - when to not name blank nodes apart
pfps: I'm worried that people seem to think that named graphs and named triples can be merged.
pfps: named graphs and RDFn and multi-edges all have differences
niklasl: that might be true - merging could be a problem
niklasl: I am not adamant about using named graphs as they are and relying on statements to signal their semantics
niklasl: in practice there is often the union default graph so there needs to be some way to control that
niklasl: I see great danger in the triple term - there is complexity - and it doesn't solve the use cases
niklasl: the qualification use case - when representation needs to incorporate new kinds of information - is a problem
niklasl: we are doing this for the use cases
niklasl: there are already requests for semantics of datasets and intergraph semantics
niklasl: my current proposal for using graphs does not depend on blank names
tl: the nested graph proposal does not actually nest graphs
tl: adrian can you send me information on your use case?
ora: I think this was a productive discussion - people are beginning to understand other positions
ora: we want a good result out of this work
ora: the classification by adrian was good
ora: what I would like to leave you with is the desire to be able to complete our work without breaking things needlessly
ora: before this meeting I was rather against doing something with graphs but it may be potential solution
ora: what is the real way forward?
ora: next week we should try to understand whether some of this work can be subdivided
there are no dumb questions only dumb answers
<tl> we didn't discuss unasserted assertions and quotation at all
adrian: could we do something with the union graph that helps us
<niklasl> The only "definition" of union default graph https://
ora: we are adjourned