15:52:30 <RRSAgent> RRSAgent has joined #rdf-star
15:52:34 <RRSAgent> logging to https://www.w3.org/2024/06/20-rdf-star-irc
15:52:34 <Zakim> RRSAgent, make logs Public
15:52:35 <Zakim> please title this meeting ("meeting: ..."), pchampin
15:52:46 <pchampin> meeting: RDF-star Working Group bi-weekly focused meeting
15:53:17 <pchampin> agenda: https://www.w3.org/events/meetings/5ecc5c5f-5cd2-410c-b97c-6b13c6b843f1/20240620T120000/#agenda
15:53:17 <agendabot> clear agenda
15:53:17 <agendabot> agenda+ Validating the baseline against use cases
15:53:48 <pchampin> previous meeting: https://www.w3.org/2024/06/13-rdf-star-minutes.html
15:53:54 <pchampin> next meeting: https://www.w3.org/2024/06/27-rdf-star-minutes.html
15:56:09 <AndyS> present+
15:57:17 <pchampin> prsent+
15:57:21 <pchampin> present+
15:57:24 <pchampin> s/prsent+/
15:57:40 <pfps> pfps has joined #rdf-star
15:57:52 <pfps> present+
15:58:18 <pchampin> present+ gkellogg
15:58:51 <fsasaki> present+ fsasaki
15:59:01 <AndyS> AndyS has joined #rdf-star
15:59:05 <AndyS> present+ gkellogg
15:59:08 <AndyS> present+
15:59:12 <fsasaki> scribe: fsasaki
15:59:26 <tl> tl has joined #rdf-star
15:59:34 <gtw> present+
15:59:40 <TallTed> TallTed has joined #rdf-star
16:00:19 <Kurt> Kurt has joined #rdf-star
16:00:20 <enrico> enrico has joined #rdf-star
16:00:29 <Kurt> q+
16:00:37 <niklasl> niklasl has joined #rdf-star
16:00:48 <enrico> present+
16:01:04 <niklasl> present+
16:01:05 <olaf> olaf has joined #rdf-star
16:01:07 <Kurt> present+
16:01:46 <olaf> present+
16:01:47 <doerthe> doerthe has joined #rdf-star
16:02:02 <doerthe> present+
16:02:02 <ora> ora has joined #rdf-star
16:02:23 <Tpt> present+
16:02:27 <ora> present+
16:02:30 <ora> chair: ora
16:02:58 <TallTed> present+
16:03:00 <TallTed> RRSAgent, draft minutes
16:03:01 <RRSAgent> I have made the request to generate https://www.w3.org/2024/06/20-rdf-star-minutes.html TallTed
16:03:18 <TallTed> scribe: fsasaki
16:03:20 <enrico> enrico has joined #rdf-star
16:03:31 <enrico> present+
16:03:36 <fsasaki> topic: baseline about use cases
16:03:45 <eBremer> eBremer has joined #rdf-star
16:03:56 <eBremer> present+
16:03:59 <fsasaki> ora: I lost track of what the baseline is, there has been so much discussion
16:04:00 <enrico> https://github.com/w3c/rdf-star-wg/wiki/RDF-star-%22baseline-with-IRI-opacity%22
16:04:11 <fsasaki> ... enrico, can you discuss the baseline briefly before we get going?
16:04:41 <fsasaki> enrico: according to the latest discussions we have a mix of transparent and opaque triple terms
16:05:02 <Souri> Souri has joined #rdf-star
16:05:02 <fsasaki> ... there is discussion if you really want to have opaque triples, that could be a discussion today
16:05:07 <Souri> present+
16:05:16 <fsasaki> ... peter introduced a minimal baseline: rdf star with only transparent triple terms
16:05:32 <niklasl> https://github.com/w3c/rdf-star-wg/wiki/RDF-star-%22minimal-baseline%22
16:05:41 <fsasaki> ora: I meant with "lost track": there are we with the issue of our view: reifiers vs. many-to-many?
16:05:56 <fsasaki> enrico: in the latest version we do not have the functionality of annotations anymore
16:06:08 <fsasaki> ... so you can have the same annotation for several triple terms
16:06:20 <fsasaki> ... we discussed that this does not hamper LPGs
16:06:54 <fsasaki> ... annotations introduces implicit policies which means: reasoning is not based on matching anymore
16:07:14 <fsasaki> ... in the baseline with transparent triple terms which are IRI opaque, there is a base language without syntactic restriction
16:07:28 <fsasaki> ... rdf entailment adds then only syntactic restrictions
16:07:48 <fsasaki> ... adding semantics only makes sense if we are in the restricted fragment
16:07:55 <fsasaki> ... that is the discussion of the last weeks
16:07:59 <fsasaki> q?
16:08:07 <ora> ack Kurt
16:08:35 <AZ> AZ has joined #rdf-star
16:08:39 <pchampin> q+
16:08:40 <AZ> present+
16:08:52 <fsasaki> kurt: I had a presentation that I gave to another group that I wanted to talk about at some point, about alternatives that might be worth exploring
16:08:53 <tl> present+
16:09:17 <fsasaki> ... if I can take 15-20 minutes I can present this, today or at a future meeting
16:09:27 <ora> ack pchampin
16:09:40 <draggett> draggett has joined #rdf-star
16:09:40 <fsasaki> ora: we have an agenda for this meeting, we can accomodate you in a future meting
16:09:48 <draggett> present+
16:10:03 <niklasl> q+
16:10:19 <fsasaki> pa: use cases should guide our decision.
16:10:42 <fsasaki> ... do we have a use case to model LPGs in RDF? that is one question
16:10:54 <AndyS> https://github.com/w3c/rdf-ucr/wiki/
16:10:57 <TallTed> https://github.com/w3c/rdf-ucr/wiki/RDF-star-for-labelled-property-graphs ?
16:11:04 <fsasaki> ... the other is: do we have a use case capturing the concerns mentioned by ora and others, also felix
16:11:15 <fsasaki> ... some arguments there usage based, how to explain things
16:11:23 <pfps> q+
16:11:25 <AndyS> https://github.com/w3c/rdf-ucr/wiki/RDF-star-for-labelled-property-graphs (but out of date?)
16:11:25 <fsasaki> ... that should be captured somehow
16:11:40 <ora> ack niklasl
16:11:56 <fsasaki> q+
16:12:16 <fsasaki> niklas: we have a minimal description of LPGs, they do not capture the concerns
16:12:26 <fsasaki> ... if we go forward it is hard to frame how we should look at them
16:12:47 <fsasaki> ... two baselines: one way to assess use cases with regards to: do they require reasoning
16:13:15 <fsasaki> ... I do not think that LPG is a use case, we should define use cases and then say: how to express them in LPG
16:13:25 <AndyS> q+
16:13:28 <TallTed> q+
16:13:30 <fsasaki> ... in that I expect that pattern matching on transparent terms are more clear
16:13:47 <ora> ack pfps
16:13:50 <pfps> Questions about what use cases cover can be answered (since six months or so) by consulting https://github.com/w3c/rdf-ucr/wiki/Summary and other pages in this wiki
16:14:12 <fsasaki> peter: since 6 months we have questions about use cases, it was available in the WG and in the wiki
16:14:17 <ora> ack fsasaki
16:14:17 <fsasaki> ... go look at the wiki
16:15:21 <ora> ack AndyS
16:15:26 <TallTed> q+ to say there are two kinds of use case -- one starts from zero and asks whether it can be satisfied by RDF and/or LPG; second says I have both RDF and LPGs and asks how they can be mixed/blended/combined
16:15:45 <fsasaki> felix: mention that LPGs are represented often as tables for vertices and edges. Showing an example how that is done could help
16:16:03 <fsasaki> andys: we are looking for a generic mapping to LPG
16:16:17 <ora> ack TallTed
16:16:17 <Zakim> TallTed, you wanted to say there are two kinds of use case -- one starts from zero and asks whether it can be satisfied by RDF and/or LPG; second says I have both RDF and LPGs and
16:16:19 <fsasaki> ...the scope for the requirement was: LPG mapping, capturing edge annotations
16:16:20 <Zakim> ... asks how they can be mixed/blended/combined
16:17:05 <fsasaki> ted: two kinds of use cases: 1) I have a pure, uncommitted data set that I could put in RDF or LPGs 2) we have been talking about: I have some data in LPGs or RDF, and how can I make those things work together
16:17:15 <fsasaki> ... that has not been discussed deeply until now
16:17:39 <niklasl> q+
16:17:53 <Kurt> q+
16:17:55 <ora> ack niklasl
16:18:19 <fsasaki> ... 2) is the more challenging one. How to bring to data sets together from two companies merging, based on RDF or LPG together and have something useful?
16:18:36 <fsasaki> niklas: there are many things in LPGs that have to be addressed, e.g. notion of IRIs, vocabularies ...
16:18:48 <fsasaki> that goes into the direction of LPG LD, s.t. like json-ld for LPG
16:19:04 <fsasaki> ... not necessarily vice versa
16:19:33 <fsasaki> ... in the support for the simple baseline: that does not stand in the way to go from LPG to RDF, it is not obvious how to go from richer RDF back again
16:20:13 <fsasaki> ... if RDF data allows to go back and forth without data loss: not sure how much this is in scope for this WG?
16:20:20 <ora> ack Kurt
16:20:29 <fsasaki> ora: lossless roundtrips are possible a pipe dream
16:21:07 <niklasl> So, how much loss is acceptable...?
16:21:07 <ora> q+
16:21:11 <fsasaki> kurt: LPG is a class of different types of graph systems, neo4j is the elephant in the room, a lot of the discussion may be "open cypher and RDF equivalency"
16:21:18 <fsasaki> ... that is an easer domain to address
16:21:41 <fsasaki> ... if you talk about the broader class of graphs, including e.g. tinkerpop, things get more difficult
16:22:02 <fsasaki> ... there is no consistency in the LPG side, RDF has the benefit that it is concise and standardized
16:22:24 <fsasaki> ... open cypher now has standardization, if we has open cypher equiv. to RDF, that may be easier
16:22:44 <ora> ack ora
16:22:54 <fsasaki> ... we need to be more specific what the target on the LPG side is and address issues one at a time
16:23:08 <fsasaki> ora: so open cypher is: the kind of LPG that open cypher implies
16:23:51 <fsasaki> ora: I had a discussion with Jesus from neo4j about this WG, he was interested but he could not participate in this WG
16:24:10 <fsasaki> ... how to deal with use cases? do we take one at a time and discuss it with respect to the baseline?
16:24:33 <fsasaki> kurt: enumerate UC first and then go through them
16:24:42 <TallTed> s/could not participate in this WG/could not participate in this WG (neo4j is not a W3C Member)/
16:25:26 <fsasaki> ora: peter, can you describe if our UCs can break up into groups?
16:25:34 <fsasaki> peter: there is a group that requires transparency
16:25:45 <fsasaki> ... another requires complete opaciity, including blank nodes
16:25:48 <TallTed> q+
16:25:53 <ora> ack TallTed
16:25:56 <fsasaki> ... and one about triple origin, which is weird
16:26:15 <enrico> enrico has joined #rdf-star
16:26:16 <fsasaki> ted: could that summary be put in the wiki page?
16:26:23 <enrico> present+
16:26:48 <fsasaki> ... this is what we would need as a group to say: only this UC needs this feature, so we do not touch it. Or: this feature is needed by all use cases
16:26:54 <Kurt> q+
16:26:58 <fsasaki> peter: sure, I can add that to the summary page
16:27:19 <ora> ack Kurt
16:27:25 <fsasaki> ora: can we look into use cases that require transparency now?
16:28:05 <fsasaki> kurt: we need to be specific what needs to be changed in RDF vs. what needs to be changed in turtle
16:28:13 <enrico> enrico has joined #rdf-star
16:28:17 <enrico> present+
16:28:17 <ora> q+
16:28:19 <fsasaki> ... some changes are new notations
16:28:23 <enrico> present+
16:28:25 <enrico> q+
16:28:34 <fsasaki> ... and somehow turtle constructs become RDF constructs
16:28:44 <AndyS> q+
16:28:50 <ora> ack ora
16:28:55 <fsasaki> .... we need to be careful what changes are syntactic sugar to be added to turtle, without requiring changes to RDF itself
16:29:10 <AndyS> q-
16:29:14 <fsasaki> ora: I assume: there are changes to RDF, i.e. the abstract syntax and semantics
16:29:15 <pchampin> q+
16:29:26 <AndyS> "Agreed Syntax" for Turtle :: https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jan/0095.html
16:29:34 <fsasaki> ... and downstream effects on serializations
16:29:34 <ora> ack enrico
16:29:56 <fsasaki> enrico: regarding LPGs, I would refer to standard GQL
16:30:04 <enrico> https://drops.dagstuhl.de/storage/00lipics/lipics-vol255-icdt2023/LIPIcs.ICDT.2023.1/LIPIcs.ICDT.2023.1.pdf
16:30:09 <fsasaki> ... to the data model the GQL standard assumes to build a query language
16:30:30 <ora> ack pchampin
16:30:31 <fsasaki> enrico: the paper summarizes nicely GQL, we can easily refer to that in our discussions
16:30:43 <fsasaki> +1 to the proposal from enrico
16:31:07 <pchampin> https://htmlpreview.github.io/?https://github.com/w3c/rdf-star-wg/blob/main/docs/seeking-consensus-2024-01.html
16:31:07 <fsasaki> pa: changes in the abstract syntax vs. concrete syntax need to be separated
16:31:30 <fsasaki> ... we had this discussion before kurt joined the group, see above link
16:31:40 <fsasaki> ... we decided to go for option 3
16:32:01 <fsasaki> ... we are well aware of the separation of concrete vs. abstract syntax changes and found consensus on that
16:32:14 <fsasaki> ... we are now working on the assumption that we will touch the abstract syntax
16:32:31 <fsasaki> ... though there are elements that are syntactic sugar like introducing double brackets
16:32:54 <pchampin> q+
16:32:55 <TallTed> q+
16:33:06 <fsasaki> ora: should we take "transparent vs. opaque" as a guidance of our use case analysis?
16:33:07 <ora> ack pchampin
16:33:42 <fsasaki> pa: nearly all UCs seem to require transparency
16:33:54 <fsasaki> ... LPG use cases require transparency plus
16:34:07 <enrico> q+
16:34:22 <fsasaki> ... opacity was introduced to enable LPG use cases
16:34:26 <ora> ack TallTed
16:34:32 <fsasaki> ... maybe we should discuss that to find consensus
16:34:55 <fsasaki> ted: that is one differentiator , but there may be others
16:35:17 <ora> ack enrico
16:35:29 <fsasaki> ...  we need a list of requirements to be able to understand potential relations between features
16:35:53 <fsasaki> enrico: opacity is needed only for the annotation of syntactic triples
16:36:29 <fsasaki> ... if nodes become transparent one can do things to graphs that are impossible with LPGs
16:36:52 <ora> q+
16:37:17 <fsasaki> with an example like "this triple has been written wrongly ...": you need to have understanding
16:37:22 <ora> ack ora
16:37:32 <fsasaki> ... the triple is just a piece of syntax that has some properties
16:37:48 <fsasaki> ora: for some people is the distinction between opaque and transparent lost
16:37:57 <pfps> q+
16:37:58 <fsasaki> ... do we have use cases that demonstrate that distinction?
16:37:59 <niklasl> q+
16:38:03 <AndyS> q+
16:38:09 <ora> ack pfps
16:38:10 <fsasaki> ... people will ask: what is the difference?
16:38:13 <gkellogg> gkellogg has joined #rdf-star
16:38:56 <gkellogg> present+ gkellogg
16:38:58 <fsasaki> peter: I tried to get answers from use case owners. They mostly did not have the situation that IRIs could help to the same thing
16:39:04 <ora> ack niklasl
16:39:11 <Kurt> q+
16:39:15 <fsasaki> ... for literals they said: of course that may be possibe.
16:39:18 <ora> ack niklasl
16:39:40 <ora> ack AndyS
16:39:41 <fsasaki> niklas: even the opaque case may be needed to be connected to s.t.
16:39:47 <enrico> q+
16:39:55 <ktk> present+
16:40:02 <fsasaki> andy: other important concepts that are hard to understand: triple terms vs. occurences
16:40:05 <ora> ack Kurt
16:40:09 <fsasaki> ... that also carefully needs to be explained
16:40:48 <fsasaki> kurt: what is the difference between a transparent and opaque IRI?
16:40:56 <fsasaki> ...  is it: bnode vs. IRI?
16:41:10 <fsasaki> ... how does one defined transparent vs. opaque?
16:41:10 <ora> ack enrico
16:41:12 <enrico> https://github.com/w3c/rdf-star-wg/wiki/RDF%E2%80%90star-examples-of-profiles
16:41:26 <fsasaki> enrico: see above link, example 7
16:42:07 <fsasaki> ... a transparent triple term talks about s.t. in your domain
16:42:18 <fsasaki> ... you want to refer to what the triple is talking about
16:42:34 <fsasaki> ... the IRI really denotes things in your domain
16:43:05 <fsasaki> ... in the case of opaque triple terms, you do not want to talk about the meaning of the triple
16:43:17 <fsasaki> ... you want to talk about the triple in the graph
16:43:31 <fsasaki> ... opaque triple terms being resolved are a triple
16:43:44 <fsasaki> ... transparent triples are statements
16:44:07 <tl> q+
16:44:20 <fsasaki> kurt: I have a structure that says: here is a term, that is a definition of opacity
16:44:47 <fsasaki> ... the combination of Sub - pred - object graph as being a resource that can be referred to. It is not talking about the subject
16:44:49 <ora> q+
16:44:50 <pchampin> "rose is a flower" → rose in this sentence is transparent / "rose has 4 letters" → rose in this sentence is opaque
16:45:03 <fsasaki> ... there is no semantics, it implies that there is no RDFs
16:45:18 <fsasaki> ... then you talk about the combination, an Opaque triple as an object
16:45:30 <fsasaki> ... you say: here is s.t. that points to the components of the triple
16:46:08 <fsasaki> ... that does not stop the reification, it just says: I have defined a reification for an entity that may or may not be in the graph
16:46:14 <AndyS> "triple T added to graph on 2024-06-20" (different from the fact described by the triple became true)
16:46:25 <enrico> q+
16:46:57 <fsasaki> kurt: maybe that is a way to have a notation to distinguish transparency from opaqueness
16:47:04 <ora> ack tl
16:47:04 <niklasl> I tried, in slide two of https://docs.google.com/presentation/d/e/2PACX-1vQd9lU1j4TPxluCe-cB0t7_BUpy8zAfeY_5hDlbwIyOB8wsiRqkRtSFP4AeflV5UsE4EqT-Y3_Jjx9q/pub (that I sent ~2 weeks ago) to quote the relevant parts as they are defined (one non-normatively) in RDF 1.1.
16:47:33 <fsasaki> thomas: question about the unasserted triples
16:47:35 <ora> q-
16:47:56 <fsasaki> ... for many use cases I took the annotation syntax as assigned
16:48:21 <fsasaki> ... for anything else, like cidoc-crm, I am lost
16:48:35 <fsasaki> ... there were mentions of customers who may need that
16:48:39 <Kurt> q+
16:48:44 <fsasaki> ... also in the community group
16:48:49 <ora> ack enrico
16:48:58 <fsasaki> ... so I better want to understand then unasserted assertations are needed
16:48:59 <pchampin> wikidata clearly needs to talk about unasserted triples
16:49:23 <fsasaki> enrico: opaque use case is about syntactic annotation
16:49:30 <fsasaki> ... it is not only about syntax
16:49:38 <fsasaki> ... clark kent - super man example
16:49:52 <tl> pchampin why?
16:49:55 <fsasaki> ... names do not co-refer, that is a common use case in logic, not in RDF
16:50:00 <pchampin> tl, see https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format#h-Statement_representation-Data_model
16:50:16 <ora> ack Kurt
16:50:23 <fsasaki> enrico: we talk about things being not ridig
16:50:32 <fsasaki> kurt: this use case is what I was talking about
16:50:35 <tl> pchampin thanks, will do
16:50:49 <fsasaki> if I have a triple that asserts a false statement, that statement should not be in the graph
16:51:00 <AndyS> "that graph at U contains the triple <<( :s :p :o )>>" -- "triple T withdrawn on 2024-06-20"
16:51:20 <pchampin> q?
16:51:24 <fsasaki> ... that is the use case for being opaque
16:51:39 <pchampin> q+
16:51:42 <tl> q+
16:51:43 <fsasaki> ... the s-p-o structure is triple like, but the assertion is not valid
16:52:15 <fsasaki> ... you can only do that by talking about triples as being s.t. being not part of the graph
16:52:30 <fsasaki> ... here being opaque means sense
16:52:35 <ora> ack pchampin
16:52:45 <fsasaki> ... you deal not with triples but reified statements
16:52:48 <niklasl> q+
16:53:00 <fsasaki> pa: we have two differentators quoting ted
16:53:03 <gtw> FWIW from my prior use of CIDOC-CRM, I'd say that often the modeling desire *is* to have unasserted triples. It probably only works with the many-to-many reifier approach where the reifier can denote something in the CRM domain (usually an Activity).
16:53:15 <fsasaki> ... there are some requirements. Would be good to start listing the requirements
16:53:28 <fsasaki> ... saying: there is consensus on this one, not on others
16:53:38 <fsasaki> ... e.g. do we need to talk about unasserted triples?
16:53:53 <fsasaki> ... in a previous meeting we said: we create a document note
16:54:01 <ora> ack tl
16:54:06 <fsasaki> ... maybe we need to be more proactive here
16:54:19 <TallTed> also, do we need to *query* unasserted triples (e.g., what has been said about Paris, whether or not those statements are asserted within the graph?)
16:54:20 <ora> ack niklasl
16:54:23 <fsasaki> thomas: do the unasserted statements be opaque or transparent?
16:54:29 <enrico> q+
16:54:55 <TallTed> q+
16:55:05 <fsasaki> niklas: see above link from a presentation on opaque nodes, a case we did not have so far
16:55:15 <fsasaki> ... I wonder if many-to-many is more important
16:55:28 <fsasaki> ... I fear that opacity may be a distraction
16:55:38 <fsasaki> ... for true opacity, use literals
16:55:48 <fsasaki> ... it is dangers to focus on opacity edge case
16:55:51 <ora> ack enrico
16:56:07 <fsasaki> enrico: I do not understand asserted vs. non asserted
16:56:21 <fsasaki> ... why do we talk about this?
16:56:25 <ora> ack TallTed
16:56:46 <fsasaki> ted: we want to be able to talk about triples that are part of the graph and are part of the reasoning
16:57:01 <fsasaki> ... and other triples that are not part of the reasoning of the graph
16:57:24 <fsasaki> ... we want to be able to get all triples back, of both types, that deals with an entity
16:58:10 <niklasl> It's in there, I'm quite certain.
16:58:17 <tl> it's not
16:58:19 <fsasaki> ... you want to be able to discover the non asserted notions of the entity but still have them *not* being part of the reasoning
16:58:39 <fsasaki> ora: we do not have a use case for that, can you write that up?
16:58:44 <niklasl> Why not?
16:58:45 <Souri> select ?r ?x ?p ?y { ?x ?p ?y } UNION { ?r rdf:reifies <<( ?x ?p ?y )>> }
16:58:50 <fsasaki> ted: I can give it a try
16:59:14 <fsasaki> enrico: agree with souri's example
16:59:24 <pchampin> RRSAgent, make minutes
16:59:26 <RRSAgent> I have made the request to generate https://www.w3.org/2024/06/20-rdf-star-minutes.html pchampin
16:59:32 <fsasaki> ora: semantics call tomorrow, adjourned
16:59:32 <tl> i will not be there tomorrow
16:59:36 <TallTed> That's not a bad query, Souri.  But it's rather complex. and demands syntactic sugar!
16:59:45 <TallTed> RRSAgent, draft minutes
16:59:47 <RRSAgent> I have made the request to generate https://www.w3.org/2024/06/20-rdf-star-minutes.html TallTed
17:00:17 <niklasl> There will be sugar.
17:00:34 <niklasl> rdf:reifies is not expected to be written out other than in (gah) edge cases.
17:00:57 <AndyS> "Agreed syntax" allows  -- UNION { << ?r | ?x ?p ?y >> }
17:02:03 <AndyS> We do need to write out the triples, not sugar, as well because people relate to different forms + it ties to the semantics.
17:02:32 <niklasl> Absolutely.
17:05:33 <niklasl> I mostly expect nice examples and Turtle serializers to utilize the sugar as much as they utilize ";" and "[ ..]" (i.e. it depends on their capability and the computing resources in relation to size of the graph).
17:23:19 <TallTed> RRSAgent, draft minutes
17:23:20 <RRSAgent> I have made the request to generate https://www.w3.org/2024/06/20-rdf-star-minutes.html TallTed
17:30:17 <gkellogg> gkellogg has joined #rdf-star
19:46:52 <pfps> pfps has left #rdf-star