15:55:51 <RRSAgent> RRSAgent has joined #rdf-star
15:55:55 <RRSAgent> logging to https://www.w3.org/2024/05/16-rdf-star-irc
15:55:55 <Zakim> RRSAgent, make logs Public
15:55:56 <Zakim> please title this meeting ("meeting: ..."), pchampin
15:56:02 <pchampin> meeting: RDF-star Working Group focused meeting
15:56:48 <pchampin> agenda: https://www.w3.org/events/meetings/0a6aa6e3-635c-42c2-baba-938c76b6ef01/20240516T120000/#agenda
15:56:48 <agendabot> clear agenda
15:56:48 <agendabot> agenda+ Feedback KG Conference
15:56:48 <agendabot> agenda+ Discuss Profiles -> 1 https://github.com/w3c/rdf-star-wg/wiki/RDF-star-profile-%22transparent%22 -> 2 https://github.com/w3c/rdf-star-wg/wiki/RDF-star-profile-%22functional-opaque%22 and possibly Singleton Properties -> 3 https://www.w3.org/2024/05/02-rdf-star-minutes.html#t08
15:57:18 <pchampin> pchampin has changed the topic to: RDF-start WG Focused Meeting - 2024-05-16 -- https://www.w3.org/events/meetings/0a6aa6e3-635c-42c2-baba-938c76b6ef01/20240516T120000/
15:57:24 <eBremer> eBremer has joined #rdf-star
15:57:33 <gkellogg> gkellogg has joined #rdf-star
15:58:37 <enrico> enrico has joined #rdf-star
15:59:52 <pchampin> scribe+
15:59:58 <gkellogg> present+
16:00:01 <pchampin> present+
16:00:02 <ora> ora has joined #rdf-star
16:00:04 <thomas> thomas has joined #rdf-star
16:00:10 <pfps> pfps has joined #rdf-star
16:00:14 <ktk> p+
16:00:25 <pfps> present+
16:00:27 <thomas> present+
16:00:30 <gtw> present+
16:00:41 <niklasl> niklasl has joined #rdf-star
16:00:43 <ora> present+
16:00:49 <ora> chair: ora
16:01:10 <eBremer> present+
16:01:11 <gkellogg> rrsagent, generate minutes
16:01:13 <RRSAgent> I have made the request to generate https://www.w3.org/2024/05/16-rdf-star-minutes.html gkellogg
16:01:20 <AZ> present+
16:01:24 <olaf> olaf has joined #rdf-star
16:01:26 <niklasl> present+
16:01:54 <TallTed> TallTed has joined #rdf-star
16:02:18 <AndyS> AndyS has joined #rdf-star
16:02:27 <AndyS> present+
16:02:57 <pchampin> topic: report of the Knowledge Graph Conference
16:02:57 <ktk> Zakim, open item 1
16:02:57 <Zakim> agendum 1 -- Feedback KG Conference -- taken up [from agendabot]
16:03:12 <pchampin> ora: the KGC keeps improving.
16:03:21 <pchampin> ... There was a panel on graph standards.
16:03:43 <pchampin> ... I gave a short overview of what's going on in our WG. There seemed to be a lot of interest in that.
16:03:49 <olaf> present+
16:04:02 <pchampin> ... There was also a lot of interest in RDF-LDP alignment.
16:04:13 <gtw> s/LDP/LPG/
16:04:17 <pchampin> ... People expressed interest in reasoning for LPG, shapes for LPG.
16:04:39 <pchampin> ... Another topic was the use of LLMs wth KGs.
16:04:53 <pchampin> ... Souri, you were here as well. Anything to add?
16:05:04 <Dominik_T> Dominik_T has joined #rdf-star
16:05:11 <Dominik_T> present+
16:05:12 <TallTed> present+
16:05:14 <TallTed> Zakim, who's here?
16:05:14 <Zakim> Present: ktk, eBremer, rubensworks, fsasaki, tl, ora, niklasl, AndyS, TallTed, pfps, olaf, gtw, doerthe, Souri, Dominik_T, AZ, enrico, thomas, gkellogg, pchampin
16:05:16 <TallTed> RRSAgent, draft minutes
16:05:17 <RRSAgent> I have made the request to generate https://www.w3.org/2024/05/16-rdf-star-minutes.html TallTed
16:05:23 <Zakim> On IRC I see Dominik_T, AndyS, TallTed, olaf, niklasl, pfps, thomas, ora, enrico, gkellogg, eBremer, RRSAgent, AZ, rhiaro, Tpt, ktk, driib5, gb, Zakim, pchampin, csarven, gtw,
16:05:23 <Zakim> ... agendabot
16:05:33 <pchampin> Souri: Alister mentioned the simplicity of the LGP model (e.g. property values limited to scalars).
16:05:50 <gtw> s/LGP/LPG/
16:05:56 <TallTed> s/p+//
16:06:08 <pchampin> ... It is important that we provide a way to align RDF with LPGs. People who don't need it don't have to use it.
16:06:44 <pchampin> ora: we are definitely not working in a vacuum. People are observing and following.
16:07:06 <TallTed> previous meeting: https://www.w3.org/2024/05/03-rdf-star-minutes.html
16:07:08 <TallTed> next meeting: https://www.w3.org/2024/05/17-rdf-star-minutes.html
16:07:09 <pchampin> ... Now the GQL is out -- provided you pay a few 100$ for access.
16:07:32 <pchampin> Zakim, open next agendum
16:07:32 <Zakim> I see a speaker queue remaining and respectfully decline to close this agendum, pchampin
16:07:32 <enrico> present+
16:07:39 <pchampin> q?
16:07:41 <enrico> q+
16:08:34 <pchampin> ack Souri
16:08:42 <Souri> Souri has joined #rdf-star
16:08:42 <pchampin> ack doe
16:08:45 <pchampin> ack enrico
16:08:47 <Souri> present+
16:08:48 <pchampin> Zakim, open next agendum
16:08:48 <Zakim> agendum 2 -- Discuss Profiles -> 1 https://github.com/w3c/rdf-star-wg/wiki/RDF-star-profile-%22transparent%22 -> 2
16:08:50 <Zakim> ... https://github.com/w3c/rdf-star-wg/wiki/RDF-star-profile-%22functional-opaque%22 and possibly Singleton Properties -> 3 https://www.w3.org/2024/05/02-rdf-star-minutes.html#t08
16:08:50 <Zakim> ... -- taken up [from agendabot]
16:08:56 <doerthe> doerthe has joined #rdf-star
16:08:59 <gtw> q+
16:09:02 <doerthe> present+
16:09:12 <pchampin> enrico: to summarize the state of the "profile" business
16:09:21 <pchampin> ... we have two profiles with largely overlaping syntax.
16:09:32 <pchampin> ... implementers can decide to implement one, or the other, or both.
16:09:47 <enrico> https://github.com/w3c/rdf-star-wg/wiki/RDF%E2%80%90star-examples-of-profiles
16:10:04 <Souri> q+
16:10:11 <pchampin> ... we need to decide if "both" is possible, and if so to decide on a syntactic marker to distinguish which is intended.
16:10:20 <pchampin> ... Niklas wrote a number of examples. (link above)
16:10:23 <ora> ack gtw
16:10:46 <pfps> q+
16:11:05 <enrico> q+
16:11:11 <pchampin> gtw: my understanding of the two profiles was in the use of different predicates.
16:11:16 <niklasl> (Enrico wrote the examples, I mostly reformatted.)
16:11:44 <pchampin> ... My concern is that the syntactic sugar is defined in a way that favors one of the profiles.
16:12:12 <pchampin> ... But looking at Enrico's examples, I am not sure. Both of them seem to use the same syntax.
16:12:40 <pchampin> enrico: the opaque triple terms have a quote around, but that's just a proposal. A nice one, in my opinion.
16:12:45 <niklasl> Another form thrown around uses <' s p o '> instead of <<'s p o'>>
16:12:55 <TallTed> RRSAgent, draft minutes
16:12:56 <RRSAgent> I have made the request to generate https://www.w3.org/2024/05/16-rdf-star-minutes.html TallTed
16:13:02 <pchampin> ... it would be fine as it does not conflict with the IRI syntax.
16:13:38 <pchampin> ... I'm not too concerned about syntax.
16:13:45 <AndyS> q?
16:14:00 <pchampin> ... We are not concerned about the predicate, but about the ability to distinguish the opaque profile from the transparent profile.
16:14:21 <pchampin> gtw: do you see this as a possibility that implementors implement both?
16:14:44 <pchampin> enrico: I have no crystal ball, but I expect everyone would implement both. I don't see a reason to implement only one.
16:15:00 <ora> q+
16:15:03 <ora> ack Souri
16:15:09 <pchampin> gtw: it sounds like it would be possible to implement both; two predicates seems an important aspect of this design.
16:16:03 <pchampin> Souri: rdf:refies could be used in triple terms, like :a rdf:reifies << :b rdf::reifies << :c :d :e >> >> .
16:16:34 <pchampin> ... Is there any demand for being able to do that? My sense is that it would be very low.
16:16:55 <pchampin> ... If that is to be included in the standard, I would prefer it to be a SHOULD than a MUST.
16:17:13 <pchampin> ... Implementations would like to not support it for performance.
16:17:31 <ora> ack pfps
16:17:32 <pchampin> enrico: the current abstract syntax forbids it. We can change that, but I don't think it would make much sense.
16:17:45 <pchampin> pfps: a couple of points should be made.
16:18:08 <pchampin> ... 1. People talk of these as profiles, but they are different from OWL profiles (different proposals, vs. parts of a bigger language).
16:18:18 <niklasl> One example would be for reifying a data event where something other was reified.
16:18:37 <pchampin> ... 2. Transparent and opaque don't matter much with rdf:reifies. It tends to make transparent things behave much like opaque things.
16:18:41 <pchampin> ora: can you elaborate?
16:18:59 <pchampin> pfps: with a reifier, you don't get the kind of inferences you would get with a regular triple.
16:19:35 <pchampin> ... With transparency, if two triples have the same denotation, you can mix and match their components.
16:19:47 <pchampin> ... But this does not apply to reifiers.
16:19:52 <eBremer> eBremer has joined #rdf-star
16:20:07 <ora> ack enrico
16:20:12 <ora> ack ora
16:20:17 <pchampin> enrico: that's fine. Different reifiers of the same triple can denote different things (a triple, an event).
16:20:19 <doerthe> q+
16:20:21 <eBremer> present+
16:20:38 <pchampin> ora: a question, just to clarify:
16:21:03 <pchampin> ... in enrico's definition, a tuple with rdf:reifies in the predicate position is not defined as a triple, right?
16:21:08 <pchampin> enrico: yes
16:21:27 <pchampin> ora: in a SPARQL query, are those tuples invisible to SPARQL triple patterns?
16:22:06 <pchampin> enrico: you can consider that we have two kinds of triples: legacy-triples, and reifies-triples. But they are all triples.
16:22:20 <pchampin> ... But all should be visible to SPARQL.
16:23:09 <pchampin> ora: I started wondering whether the association between the reifier and the triple term is really part of the graph, or if this is merely part of our book-keeping.
16:23:37 <pchampin> q+
16:23:39 <thomas> q+
16:24:02 <ora> ack doerthe
16:24:21 <pchampin> enrico: if we want to exclude reifies-triples, then they are more like "declarations", but there were arguments against separating declarations from statements.
16:25:05 <pchampin> doerthe: we got here (transparent / opaque profile) because we wanted to avoid having a reifier reifying multiple triples.
16:25:32 <pchampin> ... ora, as you were concerned about this, would the opaque profile address your profile?
16:25:47 <enrico> q+
16:25:50 <pchampin> ora: I do believe it helps us.
16:26:19 <niklasl> My impression has been that the transparency version does not work with LPGs due to it's many-to-many nature; but that the distinct opaque version makes it clearer "a priori" which graphs are "LPG-compliant"?
16:26:39 <pchampin> ... I'm extremely happy that the WG has indulged us in this regard.
16:26:56 <pchampin> ... I understand both sides of the argument. The way I look at it there are multiple dimensions to it.
16:27:06 <ora> ack pchampin
16:28:17 <Souri> q+
16:28:27 <ora> ack Souri
16:28:30 <pchampin> pchampin: what are we trying to achieve by preventing reifies-triples from being triple terms?
16:28:53 <pchampin> ... Granted this is a corner case, but I would prefer a more regular model.
16:29:29 <pchampin> Souri: yes, for completeness, we may want to allow it, but in practice people would not need that.
16:29:50 <pchampin> ... From an implementation point of view, I would make it more difficult for us to support that.
16:30:05 <gtw> +1 on this being an issue for efficient implementation
16:30:20 <pchampin> ... I'm not saying it should not be part of the standard, but if it is, the standard should allow vendors like us to not implement it.
16:30:37 <pchampin> q+
16:30:37 <AndyS> q+
16:30:44 <ora> ack thomas
16:30:50 <fsasaki> fsasaki has joined #rdf-star
16:30:54 <pchampin> ora: I can't even think of a use-case for those.
16:30:58 <fsasaki> regrets+
16:31:16 <gtw> obvious use case would be data provenance: "when did Ora insert this rdf:reifies triple?"
16:31:21 <ora> ack enrico
16:31:25 <pchampin> thomas: why not get rid of the abstract triple term as well, and define 4 elements in a triple (s p o id)?
16:32:06 <pchampin> enrico: you still need to define the relation between the triple term and the id.
16:32:16 <Souri> q+
16:32:28 <pchampin> thomas: then we need two kinds of quads. So what?
16:33:02 <pchampin> enrico: I read a lot of LinkedIn posts on this topic. You can see two camps: those who want transparent, and those who want opaque.
16:33:05 <pchampin> ... So we need both.
16:34:00 <ora> ack pchampin
16:34:37 <pchampin> ... I wanted to give an example of how we can encode LPG in RDF, making them richer.
16:35:10 <pchampin> s/an example/examples/
16:35:46 <niklasl> Very much a corner case, but e.g.: <record/version-2> rdf:reifies <<(  <publication> rdf:reifies <<(  <book> :publisher <org> )>>  )>> . # in version 1 the <publication> "reifier" just reified another triple (the publishedAt date).
16:35:59 <ora> ack AndyS
16:36:01 <enrico> q+
16:36:32 <pchampin> pchampin: I don't have a use case for reifying reifies-triples, but I am concerned that ensuring this restriction will be a hassle
16:37:11 <pchampin> ... You would need to check every triple before turning it into a triple-term.
16:37:24 <pchampin> AndyS: To add to that: this would happen quickly with SPARQL CONSTRUCT.
16:37:50 <pchampin> ... With variable you need to check it at runtime. It would create runtime errors, which would create usability problems.
16:37:51 <pchampin> q+
16:38:10 <enrico> enrico has joined #rdf-star
16:38:15 <enrico> present+
16:38:39 <pchampin> ora: is this an argument for letting all flowers bloom, or for turning them into declarations?
16:38:49 <pchampin> AndyS: I don't know how it would look as a declaration.
16:38:52 <ora> ack Souri
16:39:25 <pchampin> Souri: reacting to what Thomas said about having 4 terms.
16:39:31 <AndyS> Also - rdf:refies in property paths
16:40:29 <ora> ack enrico
16:40:31 <pchampin> ... I'm ok with having rdf:reifies. But if we wanted 4 components, there would be a way to distinguish opaque vs. transparent.
16:40:44 <pchampin> ... But I'm not pushing for the 4-components solutions.
16:41:21 <pchampin> enrico: if we used declarations instead of reifies-triples, we would be unable to query this.
16:41:32 <pchampin> ... That's why at this point I don't think we should go for declarations.
16:43:01 <pchampin> ... I suspect the regularity would not create too much implementation problems, but that's not my field.
16:43:09 <ora> ack pchampin
16:43:11 <niklasl> (this would be named triples)
16:44:17 <enrico> :-)
16:44:46 <pchampin> pchampin: to AndyS' point about irregularity: we already have that with literals as subject with SPARQL CONSTRUCT
16:45:07 <pchampin> ... we are ignoring it. Could we do the same with rdf:reifies in triple terms?
16:45:12 <Souri> q+
16:45:19 <ora> ack Souri
16:45:24 <pchampin> ... (playing the devil's advocate, I prefer regularity :->)
16:45:28 <pchampin> AndyS: this would be more confusing
16:45:58 <pchampin> Souri: and a SPARQL CONSTRUCT could end up putting triple-terms in the subject position
16:46:06 <pchampin> AndyS: yes, or bnodes in predicate position
16:47:05 <niklasl> q+
16:47:37 <pchampin> Souri: to pchampin's point, we could handle rdf:reifies in triple terms like we are currently treating those other irregularities
16:47:37 <ora> ack niklasl
16:47:54 <pchampin> niklasl: question about the LPG case and transparency.
16:48:16 <enrico> q+
16:48:21 <pchampin> ... If you migrate an LPG to RDF, you will and up with a lot of opaque stuff that you might not want to be opaque.
16:48:36 <ora> ack enrico
16:49:12 <pchampin> ... It seems to me that the opaque profile came from the need to restrict the cardinality of rdf:reifies, not from a wish from LPG people to have only opaque.
16:49:33 <ora> q+
16:49:40 <pchampin> enrico: cf. pchampin's counter-example with symmetric properties and transparent triple-terms.
16:50:05 <pchampin> ... We need opaque for a one-to-one correspondance.
16:50:35 <pchampin> q+
16:50:39 <ora> ack ora
16:50:47 <pchampin> ... If we want to talk about what these things mean (which LPGs don't do at all), you expand with transparent triple-terms.
16:50:56 <niklasl> q+
16:51:12 <pchampin> ora: that's a good point. In many ways, LPG people (if there is such a group) don't understand when we talk about semantics.
16:51:24 <pchampin> ... For them the semantics is only in their head.
16:52:45 <pchampin> enrico: there is a Property Graph Schema Language WG
16:53:01 <pchampin> ... apparently, they consider that once a PG has a schema, they can reason with it.
16:53:18 <pchampin> ora: this is a new thing for their group.
16:53:26 <ora> ack pchampin
16:55:26 <pchampin> ... The have use-cases for validating PGs, which is a valid.
16:55:44 <ora> ack niklasl
16:55:53 <pchampin> pchampin: my belief is that a one-size-fit-all tansformation will never be entirely satisfying.
16:56:13 <pchampin> ... more accurate transformation will require a kind of "context", similiar to JSON-LD.
16:56:22 <thomas> q+
16:56:51 <pchampin> niklasl: we seem to represent the lack of known semantics with opaque triples.
16:57:08 <pchampin> ...any syntax suffers from this lack, unless they are designed as concrete syntaxes for RDF.
16:57:54 <pchampin> ... If you have to edit your data once you realize you needed RDF, to change triple-terms from opaque to transparent, that might be an issue.
16:57:58 <thomas> q-
16:58:47 <pchampin> ora: we are over-time, sorry thomas, we could not talk about singleton properties
16:58:54 <pchampin> ... thanks everyone, good conversation. See you next week.
16:59:08 <pchampin> enrico: there will be a Semantics TF meeting tomorrow.
16:59:18 <pchampin> RRSAgent, make minutes
16:59:20 <RRSAgent> I have made the request to generate https://www.w3.org/2024/05/16-rdf-star-minutes.html pchampin
16:59:52 <pchampin> s/topic: report of the Knowledge Graph Conference/
16:59:55 <pchampin> RRSAgent, make minutes
16:59:56 <RRSAgent> I have made the request to generate https://www.w3.org/2024/05/16-rdf-star-minutes.html pchampin
17:03:23 <pchampin> RRSAgent, bye
17:03:23 <RRSAgent> I see no action items