IRC log of rdf-star on 2024-01-18

Timestamps are in UTC.

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:14:54 [gb]
https://github.com/w3c/rdf-star-wg/issues/4 -> Action 4 CLOSED decide on the short names of the specifications (on pchampin) due 22 Dec 2022
16:15:22 [gb]
https://github.com/w3c/rdf-star-wg/issues/2 -> Issue 2 RDF* in CBOR? (by ChristopherA)
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]
+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
17:47:29 [TallTed]
toc tou -- time of check, time of use
17:48:15 [TallTed]
https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use
17:50:02 [TallTed]
RRSAgent, draft minutes
17:50:04 [RRSAgent]
I have made the request to generate https://www.w3.org/2024/01/18-rdf-star-minutes.html TallTed
17:50:24 [pchampin]
i|ora: we have a proposal|topic: Seeking consensus
17:50:55 [pchampin]
RRSAgent, draft minutes
17:50:57 [RRSAgent]
I have made the request to generate https://www.w3.org/2024/01/18-rdf-star-minutes.html pchampin
17:51:20 [TallTed]
"HALT AND CATCH FIRE..."
17:51:26 [TallTed]
RRSAgent, draft minutes
17:51:27 [RRSAgent]
I have made the request to generate https://www.w3.org/2024/01/18-rdf-star-minutes.html TallTed
17:52:31 [ora]
"HALT AND CATCH FIRE", wasn't that like an actual (hypothetical) instruction?
17:55:57 [pchampin]
i|https://github.com/w3c/rdf-star-wg/issues/4 -> Action 4 CLOSED decide on the short names of the specifications (on pchampin) due 22 Dec 2022|
17:55:57 [gb]
https://github.com/w3c/rdf-star-wg/issues/4 -> Action 4 CLOSED decide on the short names of the specifications (on pchampin) due 22 Dec 2022
17:56:50 [gb]
https://github.com/w3c/rdf-star-wg/issues/2 -> Issue 2 RDF* in CBOR? (by ChristopherA)
17:57:04 [pchampin]
RRSAgent, make minutes
17:57:05 [RRSAgent]
I have made the request to generate https://www.w3.org/2024/01/18-rdf-star-minutes.html pchampin
17:58:29 [pchampin]
RRSAgent, bye
17:58:29 [RRSAgent]
I see no action items