15:40:31 <RRSAgent> RRSAgent has joined #rdf-star
15:40:36 <RRSAgent> logging to https://www.w3.org/2024/01/18-rdf-star-irc
15:50:15 <pfps> pfps has joined #rdf-star
15:54:31 <niklasl> niklasl has joined #rdf-star
15:55:47 <AndyS> AndyS has joined #rdf-star
15:59:14 <TallTed> present+
16:00:05 <TallTed> present+ pfps
16:00:05 <TallTed> present+ niklasl
16:00:05 <TallTed> present+ AndyS
16:00:06 <olaf> olaf has joined #rdf-star
16:00:16 <ora> ora has joined #rdf-star
16:00:26 <TallTed> agenda:  https://www.w3.org/events/meetings/5ecc5c5f-5cd2-410c-b97c-6b13c6b843f1/20240118T110000/
16:00:26 <agendabot> clear agenda
16:00:26 <agendabot> agenda+ Discussion of chairs' proposal [1]
16:00:27 <Souri> Souri has joined #rdf-star
16:00:32 <gtw> present+
16:00:33 <pfps> present+
16:00:36 <Souri> present+
16:00:48 <TallTed> meeting: RDF-star WG biweekly long meeting
16:00:59 <niklasl> present+
16:01:35 <tl> tl has joined #rdf-star
16:01:35 <ora> present+
16:01:44 <Tpt> present+
16:01:44 <ora> chair: ora
16:01:48 <tl> present+
16:01:50 <olaf> present+
16:01:54 <pchampin> present+
16:02:00 <TallTed> RRSAgent, draft minutes
16:02:01 <RRSAgent> I have made the request to generate https://www.w3.org/2024/01/18-rdf-star-minutes.html TallTed
16:02:05 <TallTed> RRSAgent, make logs public
16:02:19 <pchampin> previous meeting: https://www.w3.org/2024/01/11-rdf-star-minutes.html
16:02:28 <pchampin> next meeting: https://www.w3.org/2024/01/25-rdf-star-minutes.html
16:02:47 <pchampin> scribe+
16:02:59 <doerthe> doerthe has joined #rdf-star
16:03:06 <pfps> present+
16:03:06 <doerthe> present+
16:03:33 <AndyS> present+
16:03:52 <Timothe> present+
16:04:07 <eBremer> eBremer has joined #rdf-star
16:04:10 <Timothe> scribe+
16:04:49 <Timothe> ora: we have a proposal to start from the concrete syntax and go from there
16:04:57 <TallTed> RRSAgent, draft minutes
16:04:58 <RRSAgent> I have made the request to generate https://www.w3.org/2024/01/18-rdf-star-minutes.html TallTed
16:05:14 <TallTed> i/meeting: RDF-star WG biweekly/scribe: Timothe
16:05:24 <eBremer> !present
16:05:29 <pchampin> https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jan/0095.html
16:05:41 <TallTed> present+ eBremer
16:05:53 <TallTed> RRSAgent, draft minutes
16:05:55 <RRSAgent> I have made the request to generate https://www.w3.org/2024/01/18-rdf-star-minutes.html TallTed
16:06:04 <pchampin> https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jan/0077.html
16:06:09 <enrico> enrico has joined #rdf-star
16:06:10 <Dominik_T> Dominik_T has joined #rdf-star
16:06:13 <enrico> present+
16:06:14 <Dominik_T> present+
16:06:51 <Timothe> pchampin: I wrote about starting on the general form of the concrete syntax
16:06:58 <Timothe> ...: we generally agree on this syntax proposal
16:07:38 <Timothe> ...: now we need to agree on entailment
16:08:21 <TallTed> s/!present//
16:08:36 <Timothe> ...: in this proposal the syntax derives into standard reification
16:08:52 <enrico> q+
16:08:58 <ora> q?
16:09:13 <ora> ack enrico
16:09:15 <Timothe> ...: we would then introduce a notion of "well-formed" RDF
16:09:54 <TallTed> RRSAgent, draft minutes
16:09:55 <RRSAgent> I have made the request to generate https://www.w3.org/2024/01/18-rdf-star-minutes.html TallTed
16:10:09 <Timothe> enrico: I'm terrified by this proposal with standard reification
16:10:10 <tl> q+
16:10:12 <pchampin> q+
16:10:23 <pfps> q+
16:10:39 <Timothe> ...: this would not be compatible with current uses of standard reification
16:11:03 <ora> ack tl
16:11:09 <Timothe> ...: we could introduce "non-standard" reification, with a new alphabet, as in the CG
16:11:51 <ora> ack pchampin
16:11:55 <Timothe> thomas: we should define most precise kind of reification
16:12:47 <Timothe> pchampin: response to enrico: not worried about backward compatibility. I would be happy with RDF-star quoted triples beeing very loosly constrained in terms of semantics.
16:12:50 <eBremer> eBremer has joined #rdf-star
16:12:53 <tl> more precise like "fact" and "claim" as subclasses of rdf:Statement and refering to asserted and unasserted statements respectively
16:12:59 <enrico> q+
16:13:14 <Timothe> ...: but if there is agreement over a risk, I wouldn't oppose a new vocabulary
16:13:47 <ora> ack pfps
16:14:01 <pfps> There are a bunch of things here.   What I see as the main points are:
16:14:01 <pfps> 1/ no change to the abstract syntax
16:14:01 <pfps> 2/ no change to the semantics
16:14:01 <pfps> 3/ several concrete syntaxes have new shorthands that expand to RDF reification
16:14:04 <pfps> 4/ a new notion of well-formed RDF, which could allow for optimized implementations
16:14:24 <Timothe> pfps: agree with Pierre-Antoine, I don't see any problem with backward compat, as long as there is no change in syntax/semantics
16:14:28 <ora> q+
16:14:32 <AZ> AZ has joined #rdf-star
16:14:36 <AZ> present+
16:14:36 <ora> ack enrico
16:14:54 <niklasl> +1 to these, and let #4 be for optimization (not necessarily "bad meaning")
16:16:15 <niklasl> q+
16:16:51 <ora> ack ora
16:17:05 <Timothe> enrico: I would agree if you can write anything you want. The rdf:Statement class should be semantically defined. If its just syntactic sugar then its fine.
16:17:39 <Souri> +1 to well-formed (and ill-formed) reification
16:17:39 <pfps> The semantics that includes named triples in the domain of discourse doesn't really add anything to RDF.  Even though named triples are new they don't have any special semantics.
16:18:07 <pchampin> q+
16:18:18 <TallTed> s|let #4 be for| let 4/ be for|
16:18:34 <Timothe> ora: about point 2) (in the referenced email?): the idea that would could optimize is nice. The same idea could be used to optimize lists
16:18:58 <ora> q?
16:19:02 <ora> ack niklasl
16:19:26 <niklasl> https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jan/0094.html
16:21:05 <Timothe> niklasl: I think using reification is fine and can cover many use cases.
16:21:16 <ora> ack pchampin
16:22:20 <Timothe> pchampin: to enrico: I understand that its a shame to not be more specific about the semantics of the new syntax. However I think it's too late.
16:22:54 <enrico> q+
16:23:05 <Timothe> ...: we could say the same for classes in RDF, they are very loosly defined. People more into ontologies might find they are not used correctly
16:23:11 <Timothe> ...: its a feature not a bug
16:23:27 <tl> q?
16:23:31 <ora> ack enrico
16:24:51 <AndyS> q+
16:25:15 <Timothe> enrico: all the RDF alphabet is here so its a meta language for syntax. Its semantically void and its fine. But what if, in the wedding example, what does it mean to have a "starting date". This can't just be syntax.
16:26:04 <Timothe> ...: now where to go: say we give special meaning to these things (e.g. believe property and so on)
16:26:18 <pchampin> I prefer "weak semantics" than "semantic-less" :)
16:26:37 <Timothe> ...: I we want to stay abstract "semantic-less", we need to give support for opacity
16:26:43 <ora> ack AndyS
16:27:19 <Souri> q+
16:27:57 <Timothe> AndyS: if the syntax is in triple or nquads, the fact they are streaming is important for large datasets. If you optimize reification you can't stream anymore, you have to track
16:28:34 <Timothe> ...: about well-formedness: you can't split files anymore, because then you get ill-formed files
16:28:55 <ora> q+
16:29:02 <Timothe> ...: I propose we define a new term, reification descriptor, s-p-o that's a term
16:29:09 <Timothe> ...: then it can't be split out
16:29:16 <ora> ack Souri
16:29:18 <Timothe> ...: they have to be written out together
16:29:38 <pchampin> scribe+
16:29:41 <tl> q+
16:29:55 <pchampin> Souri: I agree with what Andy said. In practice, things come by parts, not as a whole.
16:30:12 <pchampin> ... It is important to allow for that streaming.
16:30:40 <pchampin> ... Reification maybe OK as the abstract syntax, but in the concrete syntax, inc. N-Triples, we need to have those triples packaged into one.
16:31:09 <pchampin> ... As part as *one* statement, that remove any possibility of the ill-form thing coming in.
16:31:26 <pchampin> ... Nobody expected to write the 4 triples in N-Triples.
16:31:51 <pchampin> ... N-Triples is used for streaming, it must support that adequately.
16:32:02 <ora> ack ora
16:32:31 <pchampin> ora: What I had in mind for well-formed-ness is similar to the definition of "error" in Common-LISP.
16:32:43 <pchampin> ... The spec says, in a number of places "It is an error to...".
16:32:56 <pchampin> ... Implementations can chose not to detect or signal those errors.
16:33:20 <pchampin> ... This allow to defer well-formed-ness, not necessarily at load time. Can happen later on.
16:33:33 <pchampin> ... At execution, you get undefined behaviour.
16:33:45 <pchampin> ... I realize that the optimization aspect may be difficult.
16:34:07 <pchampin> ... I'm not saying the idea is entirely without problem, but I find it attractive.
16:34:15 <pfps> q+
16:34:18 <pchampin> AndyS: would you be interested in a syntactic solution to that?
16:34:40 <pchampin> ... The idea that a term in the data model keeps the three parts together.
16:35:22 <Souri> q+
16:35:22 <niklasl> q+
16:35:38 <ora> ack tl
16:35:43 <pchampin> ... Souri's suggestion about N-Triples changes the spirit of N-Triples, if one line is not anymore a single triple.
16:36:42 <pchampin> tl: if we keep the abstract syntax unchanged, but have concrete syntaxes to help, this should address Andy's and Souri's concerns.
16:36:44 <AndyS> q+
16:37:07 <pchampin> ... We don't need a quoted term in the model to get to that.
16:37:08 <ora> ack pfps
16:37:11 <pchampin> AndyS: we do.
16:37:38 <pchampin> pfps: I'm confused as to what these streaming implementations are going to do.
16:38:16 <pchampin> AndyS: writing out your graph is a streaming operation.
16:38:36 <pchampin> pfps: if you have the graph in advance, this is not streaming.
16:39:11 <pchampin> AndyS: I'm not talking about stream-processing of RDF. Just importing triples in, or serializing triples out.
16:39:47 <pchampin> ... Triples can come in any order, but may be important for implementations.
16:40:23 <pchampin> q+
16:41:00 <ora> ack Souri
16:41:13 <pchampin> ... I repeat that we also need to consider the criticism on reification, especially the "bloat" problem.
16:42:03 <pchampin> Souri: the basic idea is to have a triple spo, and add properties to it.
16:42:16 <pchampin> ... My idea was to split this in two parts in N-Triples.
16:42:37 <pchampin> ... One statement to associate a name to spo. You don't need any more complication.
16:42:53 <pchampin> ... Users really need something along that line.
16:45:01 <pchampin> ... Also, you do not risk to break it by separating the N-Triples file in multiple parts.
16:45:17 <pchampin> ... From customers, we often get the feedback that RDF is complex and PGs are nice and simple.
16:45:25 <pchampin> ... I want to reduce this perceived complexity.
16:45:26 <ora> ack niklasl
16:45:47 <pchampin> niklasl: N-Triples is now and probably should stay a subset of Triples.
16:45:51 <pchampin> ... We need to preserve that.
16:45:51 <olaf> q+
16:46:08 <pchampin> ... N-quads has more leaway, in the sense that it is not a subset of TrIg.
16:46:34 <ora> ack AndyS
16:46:50 <ora> ack pchampin
16:47:05 <ora> ack olaf
16:47:14 <pchampin> ... [comment on implementations optimized for lists, which are even more complicated]
16:47:33 <AndyS> NQ is more fundamental for databases than NT.
16:47:39 <pchampin> olaf: about N-quads, we should not mix up N-Quads with anything meant to capture triples
16:47:44 <pchampin> ... N-Quads is for datasets.
16:48:16 <pchampin> ... We should not use the term quads, as it has a meaning different from what we are talking about.
16:48:47 <pchampin> ... To Souri: from the point of view of reading the data in, order would matter
16:49:06 <Souri> q+
16:49:06 <pchampin> ... you need to read the "naming statement" first if your named statements are stored in a different data structure
16:49:58 <pchampin> ... if a simple "s p o" triple occurs and you don't know yet that s is the name of a named triple / edge, this might cause problem
16:50:29 <pchampin> ... ???
16:50:45 <ora> ack Souri
16:51:24 <pchampin> ... Generally, I could live with considering the concrete syntax as syntactic sugar for std reification.
16:52:22 <doerthe> I have to leave, bye
16:53:03 <pchampin> Souri: In Turtle, it is ok to have, on the same line, the naming of a triple ("spo is named e") and adding a property to it ("e a b"), but in N-Triples I would separate the two.
16:54:19 <pchampin> ... About the order: there is no issue when a "naming statement" comes, there is no issue if the subject was used before.
16:54:36 <pchampin> ... What is difficult is to check for circular references.
16:54:45 <olaf> q+
16:54:50 <ora> ack olaf
16:55:09 <pchampin> olaf: circular references are indeed a problem.
16:55:24 <AndyS> q+
16:55:49 <TallTed> "Turtle, the Terse RDF Triple Language" suggests we'd need a new thing, maybe the somewhat absurd "Turntle, the Terse RDF Named Triple Language".
16:55:49 <TallTed> "N-Triples is an easy to parse line-based subset of Turtle" means that we need a new thing for this naming, perhaps "N-Named-Triples".
16:55:49 <TallTed> "N-Quads [is] an extension of N-Triples" so we probably need another new thing, perhaps "N-Named-Quads, an extension of N-Named-Triples"
16:56:03 <pchampin> ... but depending on your order in which you get the triples, you might need to move things from a data structure into another one.
16:56:20 <tl> q+
16:56:31 <pchampin> ... Consider ":s :p :o." You put this in your "reguar triples" structure.
16:57:31 <pchampin> ... Then you encounter ":a :b :c | :s" (:s is the name of a triple).
16:57:31 <ora> ack AndyS
16:57:31 <pchampin> ... Then you must move the first triple to your "annotations" structure.
16:57:31 <pchampin> s/reguar/regular
16:57:31 <tl> q-
16:57:45 <pchampin> TallTed: what is being discussed now can not be down with the existing language.
16:58:21 <AndyS> q+
16:58:28 <pchampin> ... We need new languages, this is a complete re-design and a rabbit hole.
16:58:30 <ora> ack AndyS
16:58:53 <pchampin> AndyS: about optimization, I think that olaf is talking about a different case.
16:59:17 <tl> q+
16:59:20 <pchampin> ... We initially talked about representing the reification; olaf is talking about representing the annotations.
16:59:55 <pchampin> ... Old-style reification triples can invalidate well-formed-ness.
17:00:20 <ora> ack tl
17:00:30 <pchampin> ... With triple terms, we can make the "naming statement" a regular triple, with specific predicate "rdf:nameOf" for example.
17:00:36 <ora> q+
17:01:14 <pchampin> tl: @@1
17:01:46 <pchampin> AndyS: a cycle of references i not so bad, because of the indirection introduced by the name
17:02:09 <niklasl> +1 re. reference cycles
17:02:10 <TallTed> a bit of history -- https://www.w3.org/DesignIssues/Reify.html
17:02:29 <ora> ack ora
17:02:40 <Souri> q+
17:02:58 <pchampin> ora: I'd like to gauge the group's sentiment about that direction
17:03:17 <pchampin> q+
17:03:23 <ora> ack Souri
17:03:35 <pchampin> Souri: I like the direction in which this is going.
17:03:36 <TallTed> perhaps we need rdfstar:subject, rdfstar:predicate, rdfstar:object -- similar to, but not identical to, rdf:subject, rdf:predicate, rdf:object -- to avoid breaking on previously reified data
17:04:10 <tl> s/@@1/would the problems just discussed be resolved by going back to defining the occurrence in a separate triple, eg :X rdfx:occurrenceOf << :s :p :o >>
17:04:57 <pchampin> ... about introducing a new term, with rdf:occurrenceOf,  is basically doing the same
17:05:06 <ora> ack pchampin
17:05:25 <AndyS> scribe+
17:05:53 <AndyS> pchampin: hearing needing of a triple needs to be atomic.
17:06:05 <TallTed> s/hearing needing/hearing naming/
17:06:25 <AndyS> ... Proposal mentioned: New kind naming statement
17:06:30 <AndyS> ... a graph is a usual graph and also the naming of triples.
17:07:01 <AndyS> ... Proposal mentioned: Use form in CG report with a naming triple
17:07:16 <AndyS> ... two ways of doing the same thing
17:07:34 <AndyS> ... see merits in both - prefer second
17:08:03 <AndyS> ... circular refs ... maybe define triple terms as non recursive.
17:10:07 <ktk> present+
17:10:41 <Souri> +1
17:10:48 <ora> Strapoll: should we pursue this?
17:10:48 <AndyS> Strawpoll by Ora: Is this productive direction?
17:10:51 <pchampin> ora: do people feel the current discussion is productive?
17:10:54 <ora> +1
17:10:55 <niklasl> +1
17:10:56 <pchampin> <pchampin> +1
17:10:56 <olaf> +1
17:10:57 <Tpt> +1
17:10:58 <tl> +1
17:10:58 <enrico> +1
17:10:59 <ktk> +1
17:11:02 <Timothe> <Timothe> +1
17:11:03 <TallTed> +1
17:11:04 <pfps> +1 it's as good as the other ways that have been explored
17:11:14 <gtw> +1
17:11:14 <eBremer> +1
17:11:19 <AZ> +0
17:11:24 <Dominik_T> +1
17:11:45 <AndyS> Yes to using reification the basis (or reification like thing)
17:12:09 <pchampin> ora: pfps, is this in line with option 1 in your message from some time ago?
17:12:09 <pfps> q+
17:12:22 <ora> ack pfps
17:12:27 <pchampin> pfps: I don't remember that message specifically
17:12:28 <AndyS> The Turtle syntax is good.
17:12:37 <pchampin> ... We can hash out the details tomorrow
17:12:51 <pchampin> ora: it make sense
17:13:05 <pchampin> ... we can conclude this meeting now and reconvene tomorrow.
17:13:18 <pchampin> ... Or do we want to continue this conversation now?
17:13:26 <pchampin> ... People might need some time to digest.
17:13:33 <pchampin> q?
17:13:43 <ktk> RRSAgent, draft minutes
17:13:44 <RRSAgent> I have made the request to generate https://www.w3.org/2024/01/18-rdf-star-minutes.html ktk
17:14:28 <tl> q+
17:14:33 <Souri> q+
17:15:05 <pchampin> AndyS: if we go for the reification thing, we could go for a different kind of reification.
17:15:33 <ora> ack tl
17:15:38 <ktk> Regrets: fsasaki
17:15:50 <pchampin> ... If would be good to know what people are expecting.
17:16:18 <ora> ack Souri
17:16:20 <pchampin> tl: I don't see what the expansion of the chevron syntax into naming statements means or implementations
17:17:10 <pchampin> Souri: today, reification makes an instance of rdf:Statement. What if we introduced a new type (which I'd like to call Edge, but could be something else)
17:17:37 <pchampin> ... we can say "this is a specifc type with specific properties", detached from rdf:Statement
17:17:38 <pchampin> q+
17:17:38 <ktk> q+
17:18:19 <ora> ack pchampin
17:19:09 <pchampin> :a :b :c | :e.
17:19:33 <pchampin> SELECT * WHERE { :e ?p ?o }
17:19:49 <Souri> q+
17:20:09 <ora> ack Souri
17:20:20 <pfps> A more precise statement of this is
17:20:29 <pchampin> Souri: your query would not match anything.
17:20:31 <pfps> Note that optimized systems must behave correctly so there five (four?) results from
17:20:31 <pfps>  SELECT ?s WHERE {
17:20:31 <pfps>    ?s ?p ?o .
17:20:31 <pfps>  }
17:20:35 <pfps> when querying
17:20:35 <pchampin> ... only an "edge pattern" would match
17:20:37 <pfps>  << :a :b :c >> :d :e .
17:20:43 <ora> ack ktk
17:20:44 <AndyS> Compare to -- :e rdf:occurrenceOf <<( :a :b :c )>>   # A new term thingy
17:21:12 <AndyS> q+
17:21:25 <ora> ack AndyS
17:21:48 <pchampin> AndyS: I get nervous when we start saying that an RDF graph is no longer just a set of triples
17:21:51 <Souri> q+
17:21:59 <pchampin> ... now it would be "a set of triples + a set of edges"
17:22:06 <pchampin> ... we should be very cautious about that
17:22:15 <ora> ack Souri
17:22:26 <pchampin> <pchampin> I agree, and that's why I prefer the 'rdf:occurrenceOf' way of naming
17:22:41 <AndyS> q+
17:22:51 <pchampin> Souri: we are introducing new things anyway. occurrences are not behaving the same as triples.
17:23:20 <pchampin> ... Yes, RDF 1.2 is RDF 1.1 + something, here a set of edges, which can be empty
17:23:35 <TallTed> "simple" changes can have VERY complex impacts
17:23:45 <pchampin> ... This brigdes the gap with PGs, in a backward compatible way
17:24:24 <pchampin> ... PGs has shown that this was useful; RDBs have had it from day one.
17:24:46 <ora> ack AndyS
17:24:56 <pchampin> AndyS: I agree with the objectives you state.
17:25:40 <pchampin> ... pchampin has highlighted the difference above:
17:26:06 <pchampin> ... do we had a new kind of things we describe, or a new structure in the graph
17:26:07 <pchampin> q+
17:26:39 <enrico> p+
17:27:30 <pchampin> s/do we had a new kind of things we describe, or a new structure in the graph/ are edges a new kind of terms, or a new kind of constructs in graphs
17:28:13 <pchampin> Souri: from a user's point of view, I don't really care how this is done internally
17:28:29 <pchampin> ... I'm interested in the syntax.
17:28:56 <pchampin> ... I think that a triple with the association of a name provides a better mental model.
17:29:16 <pchampin> ... That's where I'm coming from.
17:29:36 <pchampin> AndyS: if in your syntax, the vertical bar was replaced by a property "as name of", would that work for you?
17:30:08 <pchampin> Souri: in my opinion, it would be the same, but I aim to avoid the introduction of a new term.
17:30:33 <pchampin> ... I like the Turtle syntax. I would like something similar in the N-Triples syntax.
17:31:52 <pchampin> AndyS: we could also have a dedicated keyword for this "has name of" property, similar to the "a" keyword in Turtle, would that meet your usability concerns?
17:31:54 <TallTed> `<< :s :p :o >> named :fred`
17:32:27 <tl> q?
17:32:27 <pchampin> Souri: it is basically equivalent, although I would prefer a simple symbol.
17:32:41 <TallTed> `<< :s :p :o >> Ω :fred`
17:33:00 <pchampin> AndyS: it is acceptable if it is a triple. That way we don't need a new set in the definition of graphs.
17:33:18 <pchampin> Souri: we introduce new complexity at one level or another. Either at the term level, or at the graph level.
17:33:25 <ora> ack pchampin
17:33:43 <AndyS> scribe+
17:34:08 <AndyS> pchampin: question is the point where the complexity goes.
17:34:40 <AndyS> ... lean towards term extension that being said that might open up other issues
17:35:15 <olaf> q+
17:35:18 <AndyS> scribe-
17:35:24 <ora> ack olaf
17:35:35 <pchampin> olaf: I wanted to call this out explicitly:
17:36:07 <pchampin> ... AndyS, you propose that we have a new type of term (triple terms), but they can be used only as a subject of a specific predicate, and the object would be a blank node or IRI.
17:36:11 <pchampin> ... Is that the proposal?
17:36:44 <pchampin> AndyS: yes, with the caveat that this would not be a MUST
17:36:55 <pchampin> ... People could use those terms differently, and suffer the consequences
17:37:31 <pchampin> ... Just like there are good usage and bad usages of reification, there would be good usage and bad usage of this new kind of terms
17:37:43 <ktk> q+
17:37:50 <ora> ack ktk
17:38:17 <tl> can we understand
17:38:24 <tl>      << a: | :s :p :o >> :x :y .
17:38:30 <tl> as syntactic sugar for
17:38:36 <tl>     :a :isNameOf << :s :p :o >> .
17:38:39 <pchampin> ktk: did you talk about well-formed? I would like to discuss how they relate to lists.
17:38:43 <tl>     :a :x :y .
17:38:51 <tl> and then also << :s :p :o >> as syntactic sugar for standard reification quad
17:38:56 <tl> i.e. a two step sugar-ing?
17:39:33 <pchampin> ... I ran into hard problems with lists.
17:39:50 <AndyS> The recommended usage give nice syntax, the less good way gives no helper syntax.
17:39:50 <pchampin> .. If we go towards well-formed-ness, we must think of problems like that.
17:40:59 <pchampin> ora: I wrote examples in slides of how to manipulate collections, this is indeed hell.
17:41:32 <pchampin> ... What about tomorrow's call?
17:41:49 <pchampin> AndyS: can anybody who is participating actively to this discussion make it tomorrow?
17:42:11 <pchampin> olaf: I can't, but I'll be on vacation next week, so don't postpone.
17:42:17 <pchampin> q+
17:42:25 <pchampin> tl: I can make it
17:42:31 <pchampin> ora: me too
17:42:50 <ora> https://www.w3.org/groups/tf/rdf-star-semantics/calendar/
17:43:36 <ora> ack pchampin
17:45:04 <pchampin> pchampin: olaf, my understand is that you are ok with the current approach of extending the abstract syntax (either at the term level, or at the graph level)
17:45:27 <pchampin> olaf: yes; my interest is in defining the behaviour of SPARQL on top of it
17:45:58 <Tpt> Thank you for this discussion, it seems to move into a great direction!
17:46:12 <pchampin> ora: I'm encouraged by this discussion; it could be seen as a step back, but I think it is a step forward in order to produce a recommendation
17:46:35 <TallTed> RRSAgent, draft minutes
17:46:36 <RRSAgent> I have made the request to generate https://www.w3.org/2024/01/18-rdf-star-minutes.html TallTed
17:46:50 <olaf> olaf has left #rdf-star
17:46:55 <pfps> pfps has left #rdf-star
<pchampin> i|ora: we have a proposal|topic: Seeking consensus
<pchampin> regrets+ gkellogg