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