15:55:49 <RRSAgent> RRSAgent has joined #rdf-star
15:55:53 <RRSAgent> logging to https://www.w3.org/2024/08/08-rdf-star-irc
15:56:00 <ktk> meeting: RDF-star WG biweekly focused meeting
15:56:10 <ktk> Agenda: https://www.w3.org/events/meetings/23bcb331-af6e-40af-98f1-11c029455d12/20240808T120000/
15:56:10 <agendabot> clear agenda
15:56:10 <agendabot> agenda+ Final vote on singleton properties and on opaque IRIs  -> 1 https://www.w3.org/2024/08/01-rdf-star-minutes.html#t04 ; LPG problems we want to solve  -> 2 https://github.com/w3c/rdf-ucr/wiki/Summary
15:59:24 <ora> ora has joined #rdf-star
16:00:27 <eBremer> eBremer has joined #rdf-star
16:00:32 <AndyS> AndyS has joined #rdf-star
16:00:46 <TallTed> clear agenda
16:00:46 <TallTed> agenda+ Final vote on singleton properties and on opaque IRIs  -> 1 https://www.w3.org/2024/08/01-rdf-star-minutes.html#t04
16:00:46 <TallTed> agenda+ LPG problems we want to solve  -> 2 https://github.com/w3c/rdf-ucr/wiki/Summary
16:00:54 <thomas> thomas has joined #rdf-star
16:01:18 <TallTed> RRSAgent, draft minutes
16:01:20 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/08-rdf-star-minutes.html TallTed
16:01:41 <gtw> present+
16:01:43 <gkellogg> gkellogg has joined #rdf-star
16:01:46 <eBremer> present+
16:01:47 <niklasl> present+
16:01:49 <ora> present+
16:01:49 <Souri> Souri has joined #rdf-star
16:01:49 <niklasl> scribe: niklasl
16:01:55 <ora> chair: ora
16:01:55 <ktk> present+
16:01:59 <TallTed> previous meeting: https://www.w3.org/2024/08/02-rdf-star-minutes.html
16:02:00 <TallTed> next meeting: https://www.w3.org/2024/08/09-rdf-star-minutes.html
16:02:04 <TallTed> RRSAgent, make logs public
16:02:10 <thomas> present+
16:02:14 <gkellogg> present+
16:02:20 <Souri> present+
16:02:24 <TallTed> present+
16:02:24 <TallTed> RRSAgent, draft minutes
16:02:25 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/08-rdf-star-minutes.html TallTed
16:02:31 <ktk> regrets+ pchampin
16:02:35 <ktk> regrets+ olaf
16:02:47 <AndyS> present+
16:03:45 <ktk> regrets+ AZ
16:03:45 <niklasl> Topic: Final vote on singleton properties and on opaque IRIs
16:04:03 <ktk> regrets+ doerthe
16:04:31 <pfps> pfps has joined #rdf-star
16:04:41 <pfps> present+
16:04:48 <ktk> regerts- doerthe
16:05:32 <niklasl> enrico: Finalize two points: 1) close discussion on singleton properties, 2) close discussion on opacity
16:05:46 <niklasl> ...  re. opacity: an IRI should denote the same thing
16:05:51 <doerthe> doerthe has joined #rdf-star
16:05:56 <doerthe> present+
16:06:29 <TallTed> s/an IRI should denote/an IRI should always (i.e., in all contexts) denote/
16:06:35 <niklasl> ... re singleton properties: semantics implies either an automatic owl:sameAs or owl:differentFrom
16:06:53 <niklasl> ... We should be ready to stop discussing this.
16:06:55 <ktk> regrets- rthe, I
16:07:01 <ktk> regrets- doerthe
16:07:07 <niklasl> ora: Anybody else have opinions?
16:07:20 <enrico> enrico has joined #rdf-star
16:07:44 <enrico> present+
16:07:47 <doerthe> @ktk, I am here :)
16:07:51 <niklasl> ... singleton properties have come up several times the past 20 years. Discussions either don't go anywhere or have been rejected. You would have to modify your modelling to handle those.
16:07:58 <ora> q?
16:08:05 <niklasl> ... re. Opacity: the point on IRIs is well taken.
16:08:25 <niklasl> ... We should to two separate resolutions and move on.
16:08:31 <ora> PROPOSAL: Close discussion on singleton properties
16:08:38 <ktk> +1
16:08:41 <gtw> +1
16:08:41 <gkellogg> +1
16:08:42 <enrico> +1
16:08:42 <niklasl> +1
16:08:42 <doerthe> +1
16:08:43 <AndyS> +1
16:08:44 <ora> +1
16:08:45 <Souri> +1
16:08:46 <eBremer> +1
16:08:47 <thomas> 0
16:09:15 <niklasl> TallTed: To be clear. We're deciding no not do these.
16:09:26 <pfps> +1 but also that we are not doing singleton properties
16:09:31 <gtw> s/no not/to not/
16:09:38 <Souri> s/no not/to not/
16:09:38 <niklasl> ora: Yes, that's what we mean.
16:10:04 <TallTed> PROPOSAL: We are not specifying singleton properties.
16:10:41 <ora> PROPOSAL: The group will not consider semantics based on singleton properties
16:10:45 <gtw> +1
16:10:45 <gkellogg> +1
16:10:46 <TallTed> +1
16:10:46 <niklasl> +1
16:10:47 <eBremer> +1
16:10:47 <ora> +1
16:10:49 <ktk> +1
16:10:49 <thomas> 0
16:10:50 <enrico> +1
16:10:50 <pfps> +1
16:10:50 <doerthe> +1
16:10:52 <Souri> +1
16:10:55 <AndyS> +1
16:11:25 <draggett> draggett has joined #rdf-star
16:11:31 <draggett> present+
16:11:47 <ora> RESOLVED: The group will not consider semantics based on singleton properties
16:12:31 <niklasl> thomas: In some ways there is value in the notion of singleton properties, in some ways not.
16:14:08 <ora> PROPOSAL: The group will not consider semantics where IRIs denote different things in different contexts (sometimes called "opaque IRIs")
16:14:13 <gkellogg> +1
16:14:14 <ora> +1
16:14:15 <enrico> +1
16:14:15 <niklasl> +1
16:14:18 <TallTed> +1
16:14:18 <eBremer> +1
16:14:18 <Souri> +1
16:14:19 <gtw> +1
16:14:20 <AndyS> +1
16:14:22 <thomas> +1
16:14:22 <pfps> +1
16:14:25 <ktk> +1
16:14:38 <ora> RESOLVED: The group will not consider semantics where IRIs denote different things in different contexts (sometimes called "opaque IRIs")
16:15:10 <niklasl> Topic: LPG problems we want to solve
16:15:30 <TallTed> Zakim, next item
16:15:30 <Zakim> agendum 1 -- Final vote on singleton properties and on opaque IRIs  -> 1 https://www.w3.org/2024/08/01-rdf-star-minutes.html#t04 -- taken up [from TallTed]
16:15:39 <TallTed> Zakim, close agendum 1
16:15:39 <Zakim> agendum 1, Final vote on singleton properties and on opaque IRIs  -> 1 https://www.w3.org/2024/08/01-rdf-star-minutes.html#t04, closed
16:15:41 <Zakim> I see 1 item remaining on the agenda:
16:15:41 <Zakim> 2. LPG problems we want to solve  -> 2 https://github.com/w3c/rdf-ucr/wiki/Summary [from TallTed]
16:15:46 <TallTed> z, next item
16:15:52 <TallTed> zakim, next item
16:15:53 <Zakim> agendum 2 -- LPG problems we want to solve  -> 2 https://github.com/w3c/rdf-ucr/wiki/Summary -- taken up [from TallTed]
16:16:51 <niklasl> ora: Is a statement about a statement an equivalent of an LPG edge? Another question is if many-to-many is a problem for LPG interop.
16:17:07 <pfps> q+
16:17:18 <niklasl> ... That is, a single reifier for multiple triples.
16:17:19 <ora> ack pfps
16:17:55 <niklasl> pfps: We should not in any way be constrained by what cannot be done in LPGs.
16:18:36 <niklasl> ora: We (AWS) have seen customer demand for alignment with LPGs.
16:19:12 <TallTed> q+
16:19:18 <niklasl> ... If we make it impossible for an implementation no not be compliant with an RDF specification, that is a problem.
16:19:21 <pfps> q+
16:19:41 <niklasl> ... I think that the current baseline proposal could make this possible.
16:19:42 <ora> ack TallTed
16:19:54 <niklasl> TallTed: I do not understand why that would be so.
16:20:04 <AndyS> q+
16:20:21 <niklasl> ... Would Amazon formally object to an RDF 1.2 that is not perfectly aligned with LPGs?
16:20:32 <niklasl> ora: No, that's not what we're saying.
16:21:05 <thomas> q+
16:21:24 <enrico> q+
16:21:28 <niklasl> ... What we would like to see is the ability to offer an implementation where it is a level of interoperability of LPGs and RDF over the same graph. Or at least a view thereof.
16:21:58 <niklasl> ... In that regard, we're hoping that we can implement RDF 1.2 and still hold this interoperability.
16:22:00 <ora> ack pfps
16:22:39 <niklasl> pfps: We seem to be going back to the same discussion. Does Amazon not want to change an existing implementation?
16:22:46 <niklasl> ora: No, that is not true.
16:23:19 <ora> ack AndyS
16:23:23 <niklasl> TallTed: The data models are in some ways similar, but are very different in details. For instance, they are more like singleton properties; which we just decided not to do.
16:24:40 <niklasl> Andys: You said: being able to query across the models. Is it fair to say: if a mapping from LPG to RDF 1.2 is a subset of RDF 1.2, then that would fulfill your needs?
16:24:50 <niklasl> ora: Yes, RDF would be more expressive than LPGs.
16:25:12 <niklasl> AndyS: The difficult part: Can you draw out the requirements for that to happen?
16:25:52 <gtw> q+ to add that AWS interest is also in the other direction: we want some subset of RDF 1.2 to also be sensibly queryable in LPG languages
16:25:58 <niklasl> ora: It would satisfy us if an implementation of this subset would be considered a compliant implementation of RDF 1.2.
16:26:45 <niklasl> AndyS: It's how you can use it. To test that out, could it be done in RDF 1.2. ??
16:26:55 <Souri> Are we looking for a profile that only supports "many-to-one"?
16:27:32 <niklasl> ora: If we provided an implementation that only supported this subset, could we claim to have an RDF 1.2 implementation?
16:27:55 <niklasl> ... Could we have a profile of RDF 1.2 that does not mean full support?
16:28:08 <ora> ack thomas
16:28:11 <Souri> RDF1.2-Full and RDF1.2-LPG?
16:28:50 <niklasl> thomas: I don't know what this means. A proposal for such a profile would be much easier to discuss. There are many things in RDF that LPGs cannot support.
16:29:14 <niklasl> ora: I think this profile has been articulated in the past.
16:29:25 <ktk> RRSAgent, draft minutes
16:29:26 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/08-rdf-star-minutes.html ktk
16:29:33 <ora> ack enrico
16:29:39 <niklasl> ... we might nor have to change anything at this point.
16:29:47 <enrico> https://github.com/w3c/rdf-star-wg/wiki/RDF-star-and-LPGs
16:29:56 <pfps> s/nor/not/
16:30:02 <niklasl> enrico: A proposal made some time ago, discussed a lot.
16:31:06 <niklasl> ... As this stands, we can map the LPG model to RDF, and that would round-triple. There are things for the mapping still to discuss (the assertion, etc.), but not for this issue.
16:31:17 <ora> q+
16:31:41 <niklasl> ... We should not define a canonical LPG profile; we could show how it is possible.
16:32:17 <ora> ack gtw
16:32:17 <Zakim> gtw, you wanted to add that AWS interest is also in the other direction: we want some subset of RDF 1.2 to also be sensibly queryable in LPG languages
16:32:18 <niklasl> ... The details about what to see is orthogonal to this.
16:32:51 <AndyS> q+ to suggest a task force, with deadline(!), to produce a mapping from LPG (as in GQL) to RDF with query considered.
16:33:04 <niklasl> gtw: The interest of AWS is not just the mapping, we are interested in both directions of the mapping, for query languages.
16:33:23 <ora> q-
16:33:24 <niklasl> ... We want to see RDF 1.2 data queryable from LPGs.
16:33:28 <ora> ack AndyS
16:33:28 <Zakim> AndyS, you wanted to suggest a task force, with deadline(!), to produce a mapping from LPG (as in GQL) to RDF with query considered.
16:33:49 <niklasl> AndyS: Does that mean any RDF data, or RDF data conforming to a profile?
16:34:12 <niklasl> gtw: Any RDF with the caveat that things in RDF-star like the many-to-many probably can't be handled like that.
16:35:07 <gkellogg> q+
16:35:16 <Souri> RDF1.2-LPG = RDF1.2-Full - "many-to-many" .
16:35:34 <niklasl> AndyS: a concrete example would help to see the problem.
16:36:50 <niklasl> ora: The concrete problem is that we view a statement about a statement as an edge property in LPGs. A single reifier of multiple statements does not seem to be mappable to that.
16:37:15 <TallTed> Might SPARQL-in-GQL be an option to consider? something like SPARQL-in-SQL (a/k/a SPASQL) -- https://medium.com/virtuoso-blog/spasql-about-8486deecba66
16:37:17 <niklasl> AndyS: The N-ary-relationship-like effects is not possible?
16:37:17 <thomas> q+
16:38:08 <niklasl> ... Having one reifier for many triples is to have an N-ary relationship, to model the event of something with multiple relationships.
16:38:09 <TallTed> q+
16:38:38 <niklasl> ora: LPGs aside; in RDF, a statement about a statement, where the object is a node in the graph, is already an N-ary relationship?
16:38:53 <niklasl> ... We don't need to reify multiple triples for that.
16:39:10 <ora> ack gkellogg
16:39:48 <niklasl> gkellogg: A way to restate it might be: if we have a LPG profile with many-to-one, does that hold up under any entailment?
16:39:56 <Souri> :id | :john :weds :mary . :id :venue :church5 . This is a 3-ary relationship.
16:40:12 <doerthe> doerthe has joined #rdf-star
16:40:14 <niklasl> ... A triple term might entail more triples. Presumably the same reifier targets both.
16:40:18 <enrico> q+
16:40:20 <ora> ack thomas
16:41:01 <niklasl> thomas: Two options in the X-to-many: why not add all the annotations to each of those statments? Or, those together describe something, an event.
16:41:19 <niklasl> ... It wouldn't be perfect; probably not catastrophic.
16:41:49 <niklasl> ora: If we're ingesting full RDF 1.2 data and transform it on the fly to the many-to-one?
16:42:12 <niklasl> thomas: it wouldn't be a problem apart from losing the togetherness.
16:42:15 <ora> ack TallTed
16:42:21 <pfps> q+
16:43:01 <niklasl> TallTed: Is this more a problem for querying? A question for SPARQL 1.2? Like for SPARQL-in-GQL...?
16:43:27 <ora> ack enrico
16:43:29 <niklasl> ora: That's interesting.
16:43:35 <enrico> << :w2 | :liz :married :richard >> a :Marriage ; :starts 1975 .
16:43:41 <enrico> << :w2 | :richard :married-in :las-vegas >> :best-man :jim-benton .
16:43:42 <niklasl> enrico: I don't think this can be avoided.
16:43:48 <enrico> << :w2 | :liz :married-on 1975 >> :location :las-vegas .
16:44:09 <niklasl> ... This is for data integration, written in different ways - a major case for RDF.
16:44:34 <niklasl> Same reifier, same properties; different properties.
16:44:51 <niklasl> s/Same reifier/\.\.\. Same reifier/
16:44:53 <ora> ack pfps
16:44:56 <gkellogg> New syntax would be << :liz :married :richard ~ :w2 >> a :Marriage ; :starts 1975 .
16:45:17 <pfps> Multiple triples with one reifier, potentially among other things, permits provenance information to be attached to multiple triples without duplicating the provenance triples.  This was discussed a while ago in the working group and the savings were considered to be worthwhile.  For example,
16:45:17 <pfps> :r rdf:reifies << :alice :age 53 >> .
16:45:17 <pfps> :r rdf:reifies << :bob :age 54 >> .
16:45:17 <pfps> ... ... ... ... ...
16:45:20 <pfps> :r rdf:reifies << :zeke :age 22 >> .
16:45:24 <pfps> :r :source :census .
16:45:27 <pfps> :r :retrieved "20 jun 2024"^^xsd:date .
16:45:30 <pfps> :r ....
16:45:33 <pfps> This is a savings of at least two triples for each of the annotated triples.
16:45:39 <TallTed> RRSAgent, draft minutes
16:45:40 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/08-rdf-star-minutes.html TallTed
16:45:46 <niklasl> pfps: We have had a long discussion about cases for a single reifier. Such as for provenance.
16:45:46 <thomas> q+
16:45:50 <ora> ack thomas
16:46:19 <niklasl> thomas: In Enricos examples, you can have separate edges for w2, and annotate each of them with the same properties.
16:46:23 <niklasl> q+
16:46:44 <ora> ack niklasl
16:47:36 <ora> q+
16:47:46 <ora> ack ora
16:47:52 <TallTed> s|-> 2 https://github.com/w3c/rdf-ucr/wiki/Summary|-> 2 https://github.com/w3c/rdf-star-wg/wiki/RDF-star-and-LPGs|
16:48:05 <TallTed> RRSAgent, draft minutes
16:48:06 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/08-rdf-star-minutes.html TallTed
16:48:35 <niklasl> ora: From my understanding, given the current baseline proposal, we would be happy if we could have a profile where we do not support many-to-many.
16:48:47 <niklasl> ... we're not really objecting to anything.
16:48:52 <thomas> that would be ok with me
16:49:02 <pfps> q+
16:49:23 <niklasl> ... The WG would be free of this trouble. We would just like to see an LPG-friendly profile for this.
16:49:37 <enrico> q+
16:50:05 <niklasl> ... Is there an argument for why having that would be harmful?
16:50:36 <niklasl> ... We would have a hard time supporting this otherwise.
16:50:45 <ora> ack pfps
16:50:55 <gtw> q+ I think an *official* profile would be difficult to standardize for the reason gkellogg mentioned -- entailment would immediately pull you out of the profile. So it's a profile that precludes higher levels of the semweb stack.
16:51:03 <gtw> q+ to say I think an *official* profile would be difficult to standardize for the reason gkellogg mentioned -- entailment would immediately pull you out of the profile. So it's a profile that precludes higher levels of the semweb stack.
16:51:14 <niklasl> pfps: I do not like the idea of claiming LPG-friendliness. It really is about implementation.
16:51:32 <TallTed> q+
16:51:35 <ora> ack enrico
16:51:35 <AndyS> We will have to relax something. It need a lot of care to specified and frame that profile but it is one interesting way.
16:51:36 <niklasl> ... Implementation concerns are relevant, but please frame it like that if so.
16:51:43 <doerthe> q+
16:51:48 <enrico> << :w2 | :liz :married :richard >> a :Marriage ; :starts 1975 .
16:51:52 <AndyS> s/specified/specify/
16:51:54 <enrico> << :w2 | :richard :married-in :las-vegas >> :best-man :jim-benton .
16:52:07 <enrico> :liz owl:sameAs :richard .
16:52:14 <enrico> :married owl:sameAs :married-in .
16:52:21 <enrico> :richard owl:sameAs 1975 .
16:52:28 <niklasl> enrico: If this example is functional, this entailment is necessary.
16:52:54 <enrico> :richard owl:sameAs :las-vegas.
16:53:04 <TallTed> s/:richard owl:sameAs 1975 .//
16:53:27 <niklasl> ora: In a profile, that would not be accepted.
16:53:46 <thomas> q+
16:54:06 <doerthe> note that the wording was different (but let's not go there ;) )
16:54:15 <ora> ack gtw
16:54:15 <Zakim> gtw, you wanted to say I think an *official* profile would be difficult to standardize for the reason gkellogg mentioned -- entailment would immediately pull you out of the
16:54:18 <Zakim> ... profile. So it's a profile that precludes higher levels of the semweb stack.
16:54:53 <niklasl> gtw: We think of a syntactic constraint on the loader.
16:55:12 <thomas> thomas has joined #rdf-star
16:55:37 <ora> ack TallTed
16:56:12 <niklasl> TallTed: Is not doing a profile bad for RDF in general?
16:57:03 <Souri> Can we say (non-normative): Some implementations may enforce a unique(reifier) constraint in an RDF graph?
16:57:20 <niklasl> ora: It would be good for AWS to implement RDF 1.2. We really want RDF to have as wide a support as possible.
16:57:46 <niklasl> TallTed: it's a strategic decision for a vendor, customers have options.
16:58:03 <niklasl> q+
16:58:06 <AndyS> We could position this profile as a restriction pending future work. This WG does not the time and charter to fully do LPG/RDF.
16:58:44 <niklasl> ora: As Gregg said, the profile is syntactic in nature, is interesting.
16:59:15 <gkellogg> s/Gregg/Gregory/
16:59:32 <ora> ack doerthe
17:00:28 <niklasl> doerthe: Connecting to what Thomas said: if we have this profile, if you have two triple terms that denote the same thing, would you just pick one and be happy with that?
17:00:38 <niklasl> ora: I cannot give a definitive answer on that.
17:00:50 <TallTed> "One Graph" must necessarily have various sub-graphs, which have their own definitions, limitations, query languages, etc. Sub-graphs in LPG, and in RDF 1.1, and in RDF 1.2, and in SQL, etc.
17:01:02 <enrico> q+
17:01:20 <ora> ack thomas
17:01:25 <niklasl> doerthe: My main concern is that you could do the restriction, but there are problems with syntactic restrictions for something with semantics, but if we can work around that...
17:01:31 <gtw> we're over time
17:02:16 <niklasl> thomas: I made a mapping to RDF 1.1; RDF standard reification is semantic, but it is still restricted to one triple/relationship.
17:02:51 <niklasl> ... maybe add edge identifiers
17:03:26 <niklasl> enrico: In my document it is explicitly defined how to map back to LPGs.
17:03:48 <niklasl> ... it is a syntactic fragment. It is not semantic, not functional.
17:05:20 <gtw> gtw has left #rdf-star
17:05:28 <TallTed> RRSAgent, draft minutes
17:05:30 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/08-rdf-star-minutes.html TallTed
17:05:40 <gtw> gtw has joined #rdf-star
17:08:27 <ktk> rs/We should to two/We should make two/
17:08:39 <ktk> s/We should to two/We should make two/
17:12:42 <ktk> RRSAgent, draft minutes
17:12:43 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/08-rdf-star-minutes.html ktk
17:13:48 <ktk> RRSAgent, leave
17:13:48 <RRSAgent> I see no action items