15:55:02 <RRSAgent> RRSAgent has joined #rdf-star
15:55:06 <RRSAgent> logging to https://www.w3.org/2023/12/21-rdf-star-irc
15:55:13 <ktk> meeting: RDF-star Working Group Weekly Meeting
15:55:29 <ktk> Agenda: https://www.w3.org/events/meetings/5ecc5c5f-5cd2-410c-b97c-6b13c6b843f1/20231221T110000/
15:55:29 <agendabot> clear agenda
15:55:29 <agendabot> agenda+ Revisiting Use-Cases
15:55:29 <agendabot> agenda+ Discussion of Andy's post [1] and Souri's slides [2]
15:57:07 <pfps> pfps has joined #rdf-star
15:57:41 <ktk> Regrets: olaf, AZ, fsasaki
15:57:49 <ktk> RRSAgent, draft minutes
15:57:50 <RRSAgent> I have made the request to generate https://www.w3.org/2023/12/21-rdf-star-minutes.html ktk
15:57:59 <ktk> RRSAgent, make log public
15:58:30 <ktk> present+
15:59:41 <pchampin> pchampin has changed the topic to: RDF-star — 2023-12-21 Agenda: https://www.w3.org/events/meetings/5ecc5c5f-5cd2-410c-b97c-6b13c6b843f1/20231221T110000/
16:00:56 <gkellogg> gkellogg has joined #rdf-star
16:01:15 <gkellogg> present+
16:01:22 <Tpt> present+
16:02:03 <ktk> Chair: ktk
16:02:48 <gkellogg> scribe+
16:02:54 <gkellogg> zakim, who is here?
16:02:54 <Zakim> Present: ktk, gkellogg, Tpt
16:02:56 <Zakim> On IRC I see gkellogg, pfps, RRSAgent, Zakim, AndyS, Tpt, gb, AnthonySpencer, driib, ktk, Timothe, smoothsalt, joraboi445, VladimirAlexiev, SintayewGashaw, pchampin, gtw, csarven,
16:02:56 <Zakim> ... rhiaro, agendabot
16:03:55 <ktk> Regrets+ Ora
16:03:59 <gkellogg> zakim, next agendum
16:04:00 <Zakim> agendum 1 -- Revisiting Use-Cases -- taken up [from agendabot]
16:04:02 <Souri> Souri has joined #rdf-star
16:04:09 <Souri> present+
16:04:15 <AndyS> present+
16:04:19 <tl> tl has joined #rdf-star
16:04:26 <ktk> https://github.com/w3c/rdf-ucr/wiki/Summary
16:04:29 <tl> present+
16:04:42 <niklasl> niklasl has joined #rdf-star
16:04:45 <pfps> present+
16:04:46 <niklasl> present+
16:04:54 <gkellogg> pfps: I put in a pointer for the status of the use cases.
16:05:38 <ktk> q?
16:05:39 <gkellogg> ... In summary, there is an outlyer the group may not pick up about graphs. The others are agnostic about transparency, and many talk about occurrences.
16:05:41 <AndyS> q+
16:05:47 <niklasl> q+
16:05:50 <ktk> ack AndyS
16:06:07 <gkellogg> AndyS: Which ones work on triple terms? (vs occurrences?)
16:06:20 <gkellogg> pfps: Those which require talking about the triples per-se.
16:06:25 <enrico> enrico has joined #rdf-star
16:06:28 <enrico> present+
16:06:51 <gkellogg> ... The Labeled PG and the Wiki use cases have multiple subject/predicat/objecet. They also want occurrences.
16:07:02 <gkellogg> s/objecet/object/
16:07:27 <gkellogg> ... Provenance and annotations all require occurrences.
16:07:41 <gkellogg> ... I don't know of any that require talking about the actual triple term.
16:08:22 <gkellogg> pfps: the prov use cases require some abstraction from the original triple; they suffer from a problem similar to the seminal example.
16:08:37 <gkellogg> ... It could be the term or an occurrence, which may be a matter of taste.
16:08:44 <TallTed> TallTed has joined #rdf-star
16:08:50 <gkellogg> ... Prov UC don't need occurrences.
16:09:10 <gkellogg> AndyS: So they can have different groups of triples to annotate the object.
16:09:30 <gkellogg> pfps: It's often a bad idea to have two separate predicates that need to be used together to make a whole.
16:09:55 <gkellogg> AndyS: Those with a notion of time (shop hours)
16:10:12 <gkellogg> pfps: If you use something like start time and end time you need a stand-off triple.
16:10:30 <gkellogg> AndyS: They also need a particular meaning of the triple.
16:10:46 <gkellogg> ... You can't have a triple which globally asserts open times.
16:11:21 <gkellogg> pfps: Wikidata has a similar problem, as many triples have temporal qualifiers.
16:11:31 <Tpt> q+
16:11:46 <gkellogg> ... If you want to know whats true right now, you need to understand the temporal qualifiers.
16:12:02 <TallTed> present+
16:12:04 <TallTed> RRSAgent, draft minutes
16:12:05 <RRSAgent> I have made the request to generate https://www.w3.org/2023/12/21-rdf-star-minutes.html TallTed
16:12:16 <gkellogg> ... That doesn't affect the formal meaning of RDF, though. A graph is a set of triples, and you can say that that set induces a set of possible worlds.
16:12:29 <gkellogg> ... Relating a possible world to the actual world is a separate matter.
16:12:59 <gkellogg> ... An asserted triple is true in our world throughout time and space, but there are other ways of mapping these possible worlds to the way we feel our world works.
16:13:47 <gkellogg> AndyS: If you have a graph with some temporal assertion, and you assert more triples ...
16:14:09 <gkellogg> pfps: Everything is monotonic. The graph says the way the world "could" be.
16:14:23 <gkellogg> ... So the triple was true in some world at some time.
16:14:26 <TallTed> RRSAgent, make logs public
16:14:45 <gkellogg> ... Adding qualifiers adds more information. Sounds monotonic, but formally, it's not.
16:15:04 <Tpt> q+ about wikidata rank and asserted triples
16:15:16 <Tpt> q+ to talk about wikidata rank and asserted triples
16:15:28 <gkellogg> ... In CS, we do this all the time. It happens with arguments and results of formal functions, on one side it's monotonic, and on the other anti-monotonic.
16:15:44 <gkellogg> ... Purists argue against this, but somehow we keep on.
16:15:53 <ktk> q?
16:15:56 <ktk> ack niklasl
16:15:57 <TallTed> s/outlyer/outlier/
16:16:12 <gkellogg> niklasl: Mostly agreeing with the assessment on the UCs.
16:16:42 <TallTed> s|Wiki use cases have multiple subject/predicat/object|Wikidata use cases have multiple subject/predicate/object|
16:17:11 <gkellogg> ... Some of the prov examples (from biology) uses a possible stand-off predicate. If you're careful and have only one such annotation, it can work. The others commit the seminal problem.
16:17:31 <gkellogg> ... The prov vocabulary uses past-tense to make it more clear that something has once been true.
16:17:50 <gkellogg> ... E.g. "was derived from".
16:17:57 <TallTed> s/know whats true right now/know what's true right now/
16:18:02 <ktk> ack Tpt
16:18:02 <Zakim> Tpt, you wanted to talk about wikidata rank and asserted triples
16:18:05 <TallTed> RRSAgent, draft minutes
16:18:06 <RRSAgent> I have made the request to generate https://www.w3.org/2023/12/21-rdf-star-minutes.html TallTed
16:18:28 <pfps> q+
16:18:43 <gkellogg> Tpt: Wikidata has a system built in to know if a triple should be asserted or not. Each occurrence can have a rank; the main triple is asserted only if the rank is sufficient.
16:19:11 <ktk> q?
16:19:15 <gkellogg> ... Only the latest U.S. President will have a full rank, and previous would have a lower rank.
16:19:39 <gkellogg> pfps: The Liz Taylor/Dick Burton example has all relationships with the same rank.
16:19:46 <pfps> q-
16:20:07 <gkellogg> zakim, next agendum
16:20:07 <Zakim> agendum 2 -- Discussion of Andy's post [1] and Souri's slides -- taken up [from 2]
16:20:39 <gkellogg> https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Dec/0033.html
16:21:16 <gkellogg> AndyS: It starts out with a couple of objectives: exploring what edges are and taking the RDF model that triples are unique in a graph and how RDF merge works.
16:21:23 <draggett> draggett has joined #rdf-star
16:21:35 <gkellogg> ... It has occurrences used as edges, which gives you the grouping to keep information together.
16:22:02 <gkellogg> ... We've had some proposals about not keeping triples unique, but it's pretty fundamental.
16:22:24 <gkellogg> ... It also extends the notion that a triple on its own is abstract, but when put in a graph you're somehow using it.
16:22:38 <gkellogg> ... So qualification can be different for the same triple in different graphs.
16:22:42 <ktk> q?
16:22:42 <niklasl> +1 to these objectives
16:22:49 <tl> q+
16:22:59 <tl> q-
16:23:11 <gkellogg> subtopic: sourie's proposal https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Dec/att-0045/RDFn_Slides_Dec_14_2023.pdf
16:23:47 <AndyS> q+
16:23:48 <gkellogg> Souri: When we have an occurrence today we can either have them asserted or unasserted.
16:23:56 <TallTed> s/sourie's/Souri's/
16:24:02 <TallTed> RRSAgent, draft minutes
16:24:03 <RRSAgent> I have made the request to generate https://www.w3.org/2023/12/21-rdf-star-minutes.html TallTed
16:24:49 <pchampin> q+ to answer to Souri with another question
16:25:01 <gkellogg> ... (from slides), the example is of two occurrences of the Trump presidency.
16:25:13 <gkellogg> ... The second one didn't happen, but can be claimed.
16:25:25 <tl> q+
16:25:41 <gkellogg> ... According the Trump, he won in 2020. Should we aim to be able to make such statements.
16:25:48 <ktk> ack AndyS
16:26:25 <gkellogg> AndyS: In my email, I was trying to split that out, to separate whether a triple is asserted or not. They come together in the annotation syntax.
16:26:54 <gkellogg> ... In the annotation syntax, the triple is asserted.
16:27:06 <gkellogg> pchampin: My reading is that the triples are asserted, not the occurrrences.
16:27:24 <gkellogg> AndyS: Occurrences are resources; I'm not sure what it means to assert that.
16:28:03 <gkellogg> Souri: We can get an ID for an occurrence; I could use that to make statement such that it is true.
16:28:39 <ktk> q?
16:28:50 <gkellogg> AndyS: I'm not sure what the difference between having an occurrence and making a statemenet about it, how that is different that putting the triple in the graph.
16:28:55 <niklasl> q+
16:29:23 <gkellogg> Souri: I think the capability is there, but it's done a different way.
16:29:33 <gkellogg> s/Souri/AndyS/
16:30:13 <gkellogg> Souri: I have more slides to show how RDFn and RDF-star are quite close; it's a matter of what the user sees where we have a slight difference.
16:30:35 <ktk> q
16:30:36 <gkellogg> ... I'd like to see if we can give the user alternatives to use either style.
16:30:40 <pfps> q+
16:31:43 <gkellogg> pchampin: In souri's example, the annotated triple said "Trump won election".
16:32:01 <gkellogg> Souri: It was a presidential election that trump said he won.
16:32:13 <gkellogg> pchampin: Is it the concept of an election or a specific election?
16:32:32 <gkellogg> ... Depending on the meaning, I could agree with its being asserted, or not.
16:33:15 <gkellogg> ... Triples are asserted, not occurrences. When we assert a triple we endorse some fact about the world.
16:33:44 <gkellogg> ... We talk about occurrences as if it's one uniform type of thing, but this is not the case. Sometimes we want to talk about multiple things.
16:33:46 <niklasl> +1 for occurrences being what the users need them to be
16:34:47 <gkellogg> ... It's true that Trump one some election, and the fact that he didn't win in 2020 does not make the triple false.
16:35:22 <gkellogg> Souri: You'd like to have an event "Election 2020" and assert about that, rather than the abstract "election".
16:36:08 <gkellogg> pchampin: There are cases where it's okay to present such a triple, but we need to be careful.
16:36:14 <enrico> q+
16:36:26 <gkellogg> ... There could be different cases.
16:37:01 <gkellogg> Souri: It's similar to talking about who one the world cup. What if "Trump won election" was not an asserted triple.
16:37:34 <gkellogg> ... There could be something about 2016 and about 2020 and we could talk about them separately.
16:37:43 <ktk> ack pchampin
16:37:43 <Zakim> pchampin, you wanted to answer to Souri with another question
16:38:18 <gkellogg> Souri: I want to say something about the truthfulness about each individual edge.
16:39:07 <gkellogg> ... I might talk about other fictional or true events. (Brazil wins world cup).
16:39:41 <gkellogg> ... We talk about the assertion of a triple but not an occurrence. Is this a common occurence?
16:39:55 <gkellogg> ... We should provide some way to do this easily and formally.
16:40:05 <ktk> ack tl
16:40:08 <AndyS> q?
16:40:37 <gkellogg> tl: We talked about different meanings. Is it asserted/endorsed or not?
16:40:56 <gkellogg> ... We separate the triple from its assertion as the type exists only once in the data.
16:41:28 <gkellogg> ... We have a gap to bridge; you have an annotation on a triple you don't want to endorse and something else may be asserted that changes your intention.
16:41:55 <gkellogg> ... That's why I proposed having different properties to distinguish between the uses.
16:42:21 <gkellogg> ... Maybe "quote" or "opaque". Endorsed or not, asserted or not.
16:42:45 <gkellogg> ... There's a gap between the abstract triple and different assertions.
16:42:47 <ktk> q+
16:43:15 <Souri> +1 to providing a way to describe the type of occurrence
16:43:42 <gkellogg> niklasl: I understand that tl is describing and I think that is closer to the RDFn proposal than Andy's proposal.
16:44:11 <gkellogg> ... They are all pretty close to each other; the main difference is that you might have a graph including another graph ...
16:44:17 <gkellogg> tl: Not quite
16:44:49 <gkellogg> niklasl: AndyS proposal is more "classic" RDF, as a triple is asserted if its in the graph. With assertions ...
16:45:08 <gkellogg> tl: The annotation syntax works only for asserted triples.
16:45:32 <gkellogg> ... The short-hand syntax should be easy.
16:45:39 <ktk> ack niklasl
16:46:04 <gkellogg> niklasl: I'm trying to get at the problem with the unasserted triple, how do you want that to work? Is there something that can be tweaked?
16:46:14 <pchampin> tl, in the latest proposal by Andy, the chevron syntax is also a shortcut, which is entirely symmetric to the annotation syntax, without the assertion
16:46:29 <gkellogg> tl: I made a proposal for that with a predicate that determines if it is asserted or not through entailment.
16:47:06 <gkellogg> niklasl: You could say that an occurrence is asserted and this is sort of what rank does in Wikidata.
16:47:46 <gkellogg> ... I accept how things work with Andy's proposal. If an occurrence is said to be asserted, I assert it.
16:48:17 <pchampin> +1 to niklasl: occurrences are RDF resources; you can say whatever you want about them, using additional vocabularies, and leave this to the application level
16:48:25 <gkellogg> ... Perhaps the annotation syntax adds such an assertion.
16:48:47 <gkellogg> q?
16:49:01 <ktk> ack pfps
16:49:28 <Souri> q+
16:49:37 <gkellogg> pfps: Mostly on RDFn, but my issue is that we have a number of "proto-proposals" and I can't really distinguish between the quality of each (mostly RDFn)
16:49:54 <gkellogg> ... I'd like to break that down, and I can't really tell if they're the same or not.
16:50:23 <gkellogg> enrico: The discussion so far makes me think that types should not exist.
16:50:59 <gkellogg> ... If we consider "John" being a "Person", I assert John, but I don't assert Person.
16:51:20 <gkellogg> ... What does it mean that two people marry. When, Where, Now or in the past.
16:51:22 <AndyS> q+
16:51:32 <gkellogg> ... The problem of RDF is that we ...
16:51:57 <gkellogg> ... A triple I want to annotate is not something which is true.
16:52:37 <gkellogg> ... Its an n-ary relation I want to assert something about.
16:52:37 <gkellogg> ... If you leave out the additional attributes, it's meaningless, its just a type.
16:52:56 <gkellogg> ... Types are a way to refer to things. They're not something themselves.
16:53:28 <gkellogg> ... You need an objective function. Only one type but multiple triples.
16:53:33 <tl> q?
16:53:40 <gkellogg> ... This makes the RDF job harder as you need different types of things.
16:54:12 <tl> q+
16:54:16 <gkellogg> ... Types should not be explicit elements in the abstract syntax, and don't have a semantics per-se.
16:54:37 <gkellogg> ... You may want to say something about the class Person.
16:55:07 <gkellogg> ... At that point, it becomes a resource about which I can make further assertions.
16:55:07 <ktk> ack enrico
16:55:50 <ktk> q-
16:55:55 <gkellogg> ... Andy's thing is fine, but in the abstract syntax you have occurrences that have types. The meaning is not the syntactic triple itself.
16:56:29 <gkellogg> ... It may be that the triple type is equivalent to another.
16:56:40 <gkellogg> ... My perception is that types should not be there.
16:56:43 <ktk> ack Souri
16:57:19 <gkellogg> Souri: I have a couple of slides that I might present that could clarify things.
16:57:22 <Souri> An RDFn graph is a set of <s, p, o, n> tuples, where n is the "triple-name" component. Some of the tuples represent triples and rest of the tuples represent occurrences.
16:58:02 <gkellogg> AndyS: I'm not quite clear about the use of the word "type" if it's an rdfs:Class. I don't think a triple term is the same kind of type.
16:58:23 <gkellogg> ... The type is rdf:Triple, it's not the type the triple is representing.
16:58:45 <ktk> ack AndyS
16:58:46 <gkellogg> ... I didn't put types in as rdfs:Classes, and I don't really know what the answer is. I'm not sure the type/token distinction applies.
16:59:24 <gkellogg> ... With any of the ideas where properties have side-effects, are the proposals saying this works in N-Triples? Up until now, N-Triples has been a direct form.
16:59:43 <gkellogg> ... If some triples have side-effects, we've made a large change.
17:00:03 <gkellogg> ... Right now Turtle can incorporate N-Triples.
17:00:09 <pchampin> scribe+
17:00:11 <gkellogg> scribe-
17:00:12 <ktk> ack tl
17:00:44 <pchampin> tl: To Andy's last point: good question, I don't know what the solution is.
17:00:47 <niklasl> q+ +1 on not having "side-effects" (of course, optional entailment can do more...)
17:00:49 <gtw> present+
17:00:52 <pchampin> ... With entailment, I guess it would not be a problem.
17:01:25 <ktk> q?
17:01:28 <ktk> ack +1
17:01:28 <Zakim> +1, you wanted to comment on not having "side-effects" (of course, optional entailment can do more...)
17:01:32 <pchampin> ... To Enrico, I like what you are saying. Reminds me of Pat Hayes' email to the RDF 1.1 WG, that niklasl mentioned.
17:01:35 <niklasl> q- +1
17:02:00 <pchampin> ... On the other hand, when we talk about types in RDF, we are really talking about deduplication, early optimization.
17:02:17 <pchampin> ... We are not just talking about the type, we are talking about similarity between occurrences.
17:02:46 <niklasl> q+
17:02:55 <pchampin> ... I understand that the definitions are in line with what is usually done in logic, but it creates difficulties in understanding.
17:02:56 <ktk> ack niklasl
17:03:28 <pchampin> niklasl: When we say "type of triple", I think of "pattern of triple".
17:04:09 <pchampin> ... I'm thinking about Andy's proposal, how it can work with triples only in the object position.
17:04:48 <pchampin> ... Also thinking about using a literal in the object position to describe the triple.
17:05:42 <pchampin> ... I'm not sure where to put my energy now.
17:06:02 <pchampin> ... I like that Andy's position does not require us to put triple terms in triple terms, mitigating the complexity.
17:06:27 <tl> q?
17:06:37 <pchampin> ... Similarity with Notation3 -- I think about it a lot, even if it is out of scope for this group.
17:07:07 <pchampin> [Souri presents slides]
17:07:34 <pchampin> Souri: I wanted to explore the relation between RDFn and RDF-star
17:08:46 <pchampin> ... In RDFn, the triple itself is named in the rdft: namespace, with a suffix computed from (s, p, o)
17:09:05 <pchampin> ... Occurrences are named with custom identifiers.
17:09:43 <pchampin> ... (next slide)
17:11:01 <pchampin> ... [describes Andy's proposal using the same figure]
17:11:16 <tl> q+
17:12:02 <pchampin> ... As niklasl said earlier, I'm concerned about the ability to embed triple terms in triple terms
17:13:18 <pchampin> ... That's where I'm coming from: some people don't like the quoted triples.
17:13:22 <niklasl> q+
17:13:34 <ktk> ack tl
17:13:57 <pchampin> tl: I don't like the possibility of generating a name from s, p, o .
17:14:17 <pchampin> ... Rather use a fresh blank node at each occurrence.
17:14:40 <pchampin> ... Talking about the meta-level (the type) should be explicit.
17:15:03 <pchampin> Souri: the generation of the name is to provide the unicity of the triple.
17:15:51 <pchampin> q+
17:16:21 <pchampin> ... (something about preventing occurrence names to be used as predicates)
17:18:33 <pchampin> ... the generated rdft: identifier allows the parser to determine that we are talking about the triple. Let's talk offline.
17:19:05 <pchampin> niklasl: I would like Andy's proposal to be the same as what you are proposing, but I'm not sure.
17:19:18 <pchampin> ... In your proposal, can triples and occurrences both be asserted?
17:19:39 <pchampin> Souri: I'm storing whether the triple is asserted or not.
17:19:47 <pchampin> ... The occurrence is only referring to the triple.
17:20:47 <ktk> ack niklasl
17:20:49 <pchampin> ... Like AndyS said, it is useful to come back to N-Triples.
17:20:59 <ktk> q+
17:21:07 <pchampin> ... (shows example of RDFn-N-Triples in slide)
17:22:12 <pchampin> niklasl: AndyS, is it correct that your proposal does not require triple terms in triple terms?
17:22:37 <pchampin> AndyS: that would still be possible
17:23:07 <pchampin> Souri: isn't it a requirement that you are able to also talk about the triple itself?
17:23:57 <pchampin> AndyS: what I wrote was: we would not allow the shortcut syntax of occurrences inside triple terms.
17:24:58 <gkellogg> q+
17:25:20 <pchampin> ... In N-Triples anyway, the shortcut syntax does not exist and is replaced with the rdf:occurrenceOf triple.
17:26:12 <pchampin> Souri: In N-Triples for RDF-star, we can only use rdf:occurrenceOf followed by a triple term that may contain the name of another triple.
17:26:15 <ktk> q-
17:27:00 <pchampin> AndyS: we can't rule out that someone takes RDF 1.2 to make assertions about assertions.
17:27:24 <pchampin> Souri: what I wanted to say was that those things are very close to each other.
17:27:51 <pfps> I again dispute this a version of RDF based on multi-graphs is very different from one based on regular graphs.
17:28:29 <pchampin> ... As long as we have an N-Triples serialization to associate a name to a triple...
17:28:34 <tl> q?
17:28:53 <niklasl> q+
17:29:03 <ktk> ack pchampin
17:29:58 <enrico> q+
17:30:22 <pchampin> pchampin: I see convergence between Souri's proposal and AndyS's proposal.
17:30:35 <pchampin> ... To pfps: do you consider AndyS's proposal sufficiently described?
17:31:12 <Souri> q+
17:31:14 <Souri> q+
17:31:21 <pchampin> pfps: AndyS's proposal is not too bad, because there is not too much in it. It reuses things described before.
17:32:09 <pchampin> ... One problem with the RDFn is that I don't know what the names of triples are. Are they a new thing? Can they by IRIs? Lirerals?
17:32:38 <pchampin> Souri: very quicky: they are special IRIs.
17:32:50 <pchampin> pfps: you have to tell me what a "specia IRI" is.
17:32:55 <TallTed> an EBNF of RDFn would likely answer all our questions ... but certainly would be very formal.
17:33:16 <pchampin> Souri: just like 'rdf:' IRIs
17:33:40 <pchampin> pfps: ok, so special IRIs are IRIs in a particular namespace. Are they forbidden for use elsewhere?
17:33:50 <pchampin> ... All this need to be written down in a document, so that we can look at it.
17:34:15 <ktk> ack gkellogg
17:34:28 <pchampin> gkellogg: in my interpretation of Souri's slide: the difference between a triple type and an occurrence is determined by their name
17:34:47 <pchampin> ... this is very unlike RDF. Names in RDF have no meaning.
17:35:08 <pchampin> ... In AndyS' proposal, triple types do not have name, hence the need for recursion.
17:35:10 <pchampin> q+
17:35:50 <pchampin> ... AndyS's proposal leverages what we have already worked on.
17:36:00 <ktk> ack niklasl
17:36:49 <pchampin> niklasl: if you interpret occurrences from a LPG point of view, they are edges.
17:36:49 <ktk> thanks gkellogg
17:37:00 <ktk> and happy holidays
17:37:15 <AndyS> q+
17:37:41 <AndyS> <<:s :p :o >> :p1 :z ; :p2 "abc" .
17:37:45 <ktk> q?
17:37:46 <AndyS> q-
17:37:47 <pchampin> ... I see an opportunity in the fact that the same name can be declared as occurrence of several triples.
17:37:51 <tl> q+
17:38:00 <pchampin> ... May be not ready to represent graphs right now, but a good opportunity.
17:38:19 <pchampin> enrico: we still needs at least a hint about the semantics for this proposal.
17:38:31 <Souri> q-
17:38:32 <pchampin> ... Once we start working on this we may realize some proplems.
17:38:52 <pchampin> ... The triple occurrence is some kind of shortcut for the triple term.
17:38:58 <pchampin> ... Why not the other way around?
17:39:42 <pchampin> ... Allowing triple terms in any position would be too extreme. But restricting them in the object position of some predicate is weird.
17:39:46 <ktk> ack enrico
17:40:19 <pchampin> AndyS: if we have only occurrences, we need a way to know what are its the subject, predicate, object
17:41:43 <niklasl> q+
17:42:42 <ktk> ack pchampin
17:43:12 <pchampin> pchampin: to Enrico: my proposal to restrict triple terms to only some predicates was only a *profuke
17:43:25 <pchampin> s/profuke/profile*, not a core constraint
17:44:13 <pchampin> ... about the complexity of triple terms: if they are to be extended later  to graph terms, then the complexity should not be considered an issue
17:44:28 <pchampin> tl: we need graph terms in this version of RDF, otherwise somebody else will do it.
17:45:39 <ktk> q?
17:45:41 <ktk> ack tl
17:45:46 <pchampin> ... Some triples stores may have not much use for triple terms. They may implement the shortcut syntax using reification.
17:46:37 <pchampin> ... The shortcut syntax should be in the core and mapped to standard reification, with additional mappings to triple terms and graph terms.
17:47:20 <pchampin> ... The RDF 1.1 worked hard on named graphs and came up with a description of the problems. I think we can solve them.
17:47:48 <gkellogg> gkellogg has joined #rdf-star
17:47:51 <pchampin> ... If no one answers to my counter-arguments on the mailing list, there is nothing more to do.
17:48:39 <pchampin> niklasl: I'm equaly concerned with the complexity of graph terms than with that of triple terms.
17:48:50 <pchampin> ... I have been advocating for blank graphs, different.
17:49:00 <pchampin> s/blank/blank named/
17:49:17 <ktk> ack niklasl
17:49:31 <pchampin> ... (something about named graphs)
17:49:45 <pchampin> ... I like the idea of typing annotations with rdf:Assertion .
17:50:09 <pchampin> ... I like the idea of restricting the recursiveness.
17:50:39 <pchampin> ... I'm less concerned about the recursiveness in the object position.
17:50:42 <pchampin> q+
17:51:45 <pchampin> ... To be discussed in the semantics TF.
17:52:08 <pchampin> AndyS: if there is a TF discussion, there needs to be feedback to the group.
17:52:41 <ktk> ack pchampin
17:55:25 <tl> q+
17:57:11 <pchampin> pchampin: my take away is that:
17:57:17 <Souri> Merry Christmas and Happy New Year to everyone!
17:57:24 <pchampin> ... we are generally agreeing on the concrete syntax proposed by AndyS, focusing on occurrences
17:57:45 <tl> what is the difference between a nested triple term and  graph term?
17:57:53 <niklasl> Thank you all!
17:58:13 <pchampin> ... we need to decide how, in the abstract syntax, to relate occurrences to what they are ocuurences of
17:58:25 <pchampin> ... could be via triple terms, via standard reification
17:58:57 <pchampin> ... but some of us would prefer if it didn't involve recursive structure
17:59:06 <pfps> pfps has left #rdf-star
17:59:09 <pchampin> ... (triple terms could be restricted to only contain "atomic" terms)
17:59:59 <pchampin> RRSAgent, make minutes
18:00:00 <RRSAgent> I have made the request to generate https://www.w3.org/2023/12/21-rdf-star-minutes.html pchampin
18:42:52 <gkellogg> gkellogg has joined #rdf-star
19:01:12 <gkellogg> gkellogg has joined #rdf-star
19:36:13 <gkellogg> gkellogg has joined #rdf-star
19:45:36 <gkellogg> gkellogg has joined #rdf-star
20:30:24 <gkellogg> gkellogg has joined #rdf-star
20:54:11 <gkellogg> gkellogg has joined #rdf-star
21:30:30 <gkellogg> gkellogg has joined #rdf-star
21:31:00 <gkellogg> gkellogg has joined #rdf-star
21:35:08 <gkellogg> gkellogg has joined #rdf-star
21:41:45 <driib> driib has joined #rdf-star
22:19:13 <driib> driib has joined #rdf-star
23:00:39 <gkellogg> gkellogg has joined #rdf-star
23:29:57 <gkellogg> gkellogg has joined #rdf-star
23:53:11 <gkellogg> gkellogg has joined #rdf-star
<pchampin> previous meeting: https://www.w3.org/2023/12/14-rdf-star-minutes.html
<pchampin> next meeting: https://www.w3.org/2024/01/04-rdf-star-minutes.html