IRC log of rdf-star on 2024-06-20

Timestamps are in UTC.

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