15:02:29 <RRSAgent> RRSAgent has joined #rdf-star
15:02:33 <RRSAgent> logging to https://www.w3.org/2024/03/01-rdf-star-irc
15:02:33 <Zakim> RRSAgent, make logs Public
15:02:34 <Zakim> please title this meeting ("meeting: ..."), pchampin
15:02:44 <pchampin> meeting: RDF-star Semantics task force
15:03:02 <TallTed> TallTed has changed the topic to: RDF-star WG — Semantics TF — 2024-03-01 agenda: https://www.w3.org/events/meetings/6d0cd306-0be8-4267-865a-6272cc8d9da4/20240301T100000/
15:03:29 <gkellogg> gkellogg has joined #rdf-star
15:03:59 <Souri> Souri has joined #rdf-star
15:04:13 <Souri> present+
15:04:20 <pchampin> present+
15:04:30 <tl> present+
15:04:47 <ora> present+
15:04:54 <gkellogg> present+
15:05:22 <TallTed> present+
15:05:32 <TallTed> RRSAgent, draft minutes
15:05:33 <RRSAgent> I have made the request to generate https://www.w3.org/2024/03/01-rdf-star-minutes.html TallTed
15:05:40 <niklasl> present+
15:05:40 <TallTed> RRSAgent, make logs public
15:06:25 <TallTed> next meeting: https://www.w3.org/2024/03/07-rdf-star-minutes.html
15:06:25 <TallTed> previous meeting: https://www.w3.org/2024/02/29-rdf-star-minutes.html
15:08:22 <olaf> olaf has joined #rdf-star
15:14:09 <AndyS> AndyS has joined #rdf-star
15:14:31 <TallTed> q+
15:15:10 <AndyS> present+
15:15:37 <pchampin> scribe+
15:15:59 <pchampin> topic: discussion on Enrico's examples in https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Feb/0061.html
15:16:08 <ora> ack TallTed
15:16:27 <pchampin> olaf: I find the last example (Enrico's birth) puzzling
15:16:51 <pchampin> souri: representing N-ary relationship: either as a vertex with N properties, or an edge with N-2 properties
15:17:32 <pchampin> ... but you need to chose which of the 2 properties are represented by the source and destination of the edge
15:17:42 <pchampin> ... this is a matter of perspective
15:18:37 <pchampin> TallTed: RDF is different from the relational model; it is schemaless
15:18:37 <Souri> q+
15:18:55 <pchampin> ... you add properties about a node; you don't need to know in advance what properties you need.
15:19:43 <pchampin> ora: we need to think not only of the data, but also of the queries.
15:19:44 <TallTed> s/schemaless/schema last/
15:21:11 <pchampin> ... A model of the academic world may say "thesis have an author and an advisor",
15:21:12 <ora> ack Souri
15:21:13 <TallTed> +1 yes, this comes to the fore when articulating a query ... which is *usually* the largest justification for collecting the data in the first place. Sometimes (often) you don't know what question will be the most important/revealing in the end, but you do know you'll be wanting to question.
15:21:32 <pchampin> ... but I may build a query to get the author's advisor -- I don't care about the thesis.
15:22:01 <pchampin> q+
15:22:19 <ora> q+
15:23:12 <pchampin> Souri: data evolves, that's why perspectives are important.
15:23:26 <pchampin> ... It is ok to first model a wedding with a binary relation.
15:25:05 <tl> q+
15:25:09 <pfps> pfps has joined #rdf-star
15:25:22 <pfps> present+
15:25:22 <pfps> q+
15:25:29 <pchampin> ... An N-ary relationship could be seen as N*(N-1) binary relations, depending on the focus of the person querying.
15:25:40 <pfps> q+ to mention expressive power
15:25:40 <ora> ack pchampin
15:25:45 <olaf> scribe+
15:26:23 <olaf> pchampin: My question on this perspective is that, I would have considered this an inferencing-related problem
15:26:45 <olaf> ... and, then, do I need RDF-star for that?
15:27:06 <olaf> ... the annotation can be seen as provenance
15:27:20 <olaf> ... which may be interesting to keep
15:27:25 <ora> ack ora
15:27:43 <olaf> ... but sometimes I want to infer a binary view of an n-ary relation
15:27:49 <olaf> scribe-
15:28:07 <Souri> q+
15:28:22 <pchampin> pchampin: inferring the binary relations from the N-ary relation is useful, but do we need RDF-star / rdf:reifies for that?
15:28:34 <ora> ack tl
15:29:00 <pchampin> ora: some people claim we need hypergraphs. Maybe we should keep that in mind.
15:29:25 <niklasl> q+
15:29:27 <pchampin> tl: notion of shortcut relation.
15:29:42 <pchampin> ... The actual triples are optimized in the perspective of the use-case.
15:31:14 <pchampin> ... Getting a triple, you can find back the N-ary relation this triple came from.
15:31:23 <ora> ack pfps
15:31:23 <Zakim> pfps, you wanted to mention expressive power
15:31:35 <pchampin> s/shortcut relation/shortcut relation in the cultural domain
15:32:22 <pchampin> pfps: at high enery levels, everything looks the same, but that's not where we live.
15:32:50 <pchampin> ... RDF is a low energy level environment, when many things (e.g. rules) don't exist.
15:33:06 <niklasl> +1 - choice is key (a predicate is a chosen (low-level) simplification)
15:33:09 <ora> ack Souri
15:33:28 <ora> +1 to what pfps said
15:33:44 <pchampin> Souri: true, we have to make choices. Rules may come from outside.
15:34:06 <pfps> in the low-expressivity RDF environment one has to make representational choices, these choices are *not* equivalent, and users see artifacts induced by these choices
15:35:22 <pchampin> ... When the data evolves (2-ary to 3-ary relation), we need to ensure that old queries still work.
15:35:25 <pfps> in RDF 1.1, the (sole) way of representing n-ary relationships is reification - creating a node for the relationship and separate links for each of the n parts of the relationship.  This is a simple, flexible, and powerful mechanism, but can be cumbersome.
15:36:12 <ora> q+
15:36:30 <tl> to counter pfps: we are here because people find the degree of simplification that RDF imposes on them too much
15:36:45 <pfps> In labelled property graphs, there are two ways (but both are flawed).  You can do the RDF 1.1 way, or take one of the relationships as primary, use it as an edge and add the other n-1 as attributes (or whatever they are called there).
15:37:09 <olaf> scribe+
15:37:19 <ora> ack niklasl
15:37:30 <doerthe> doerthe has joined #rdf-star
15:37:38 <doerthe> present+
15:38:08 <TallTed> How much existing RDF has been analyzed to come to this conclusion of "arity of (close to) 2"? There's a *LOT* of RDF data out there in the wild, 20 years into RDF...
15:38:19 <olaf> niklasl: I think that many people understand the n-ary relation case
15:38:34 <pfps> The notion of arity is entirely dependent on representational choices, at least in low-energy environments.  One clear benefit of triples (i.e., binary relationships) is that they are adequate to encode all relationships, precisely because of reifications.
15:38:36 <olaf> ... should be put that use case in the front?
15:38:48 <ora> q-
15:38:49 <olaf> s/be/we
15:38:56 <olaf> ... maybe not
15:39:18 <olaf> ... RDF-star can be used for many other things as well
15:39:22 <ora> q+
15:39:50 <olaf> ... It is like adding post-its
15:39:58 <olaf> scrbe-
15:40:01 <olaf> scribe-
15:40:13 <pchampin> s/scrbe-/
15:40:14 <olaf> s/scrbe//
15:40:17 <pfps> So, in some very strong sense, *everything* is binary.  One of the clear problems with relational data is its inability to correctly represent unknown values in n-ary relationships.  Reification does not have this problem, but is forbidden in most normal forms for relational data bases.
15:40:21 <niklasl> https://hackmd.io/@niklasl/HJ3IudCdp
15:40:58 <ora> ack ora
15:41:00 <pfps> q+
15:41:26 <pchampin> ora: about what pfps wrote in the char:
15:41:38 <ora> ack pfps
15:41:45 <pchampin> ... in PGs you can only add scalar properties on edges, so you can't model hypergraphs.
15:42:06 <pchampin> ... In some sense, what we are adding to RDF is more expressive than PGs.
15:42:12 <Souri> q+
15:42:19 <pchampin> ... And in some sense, it is simpler (unified).
15:42:24 <pfps> q+
15:42:30 <ora> ack Souri
15:43:02 <pfps> Certainly RDF-n is more expressive than labelled property graphs because it does not have the limitation that edge decorations cannot point to other nodes.
15:43:05 <pchampin> Souri: I agree that our proposal is more expressive than PG.
15:43:32 <ora> ack pfps
15:43:36 <pchampin> ... In PG, when you need to change edges into vertices, you are ruining all existing queries.
15:44:05 <pchampin> pfps: yes, but the solutions only address a small part of the changes that one may need to make.
15:44:23 <Souri> q+
15:44:28 <pchampin> ... A large class of changes will require the queries to change.
15:44:47 <niklasl> q+
15:44:49 <ora> ack Souri
15:45:25 <pchampin> ... If you decide that the most important thing about a mariage is not the two participants but the place where it happened, you need to rewrite your queries.
15:45:46 <ora> ack niklasl
15:45:50 <ora> q+
15:46:05 <pchampin> Souri: if you decide to add additional information to your existing data, *pre-existing* queries should not be forced to change.
15:46:38 <pfps> My point is that only *some* pre-existing queries remain the same when a previously binary relationship is changed to quasi-n-ary.  So any argument that *some* queries do not need to be changed has to come with an argument that the other queries do not matter (much).
15:46:42 <pchampin> niklasl: shorthand properties: I've used them by (ab)using OWL property chain axioms.
15:47:48 <pchampin> ... but you can only infer the shorthand from the whole path, not the other way around.
15:49:20 <pfps> There is expense and then there is expense.  OWL (often!) requires more computational support but (often?) requires less human support.   Balancing these two expenses is a knowledge engineering decision, unfortunately influenced by non-engineering environmental concerns.
15:49:38 <pchampin> ... [example of "contributor" relation, where the exact role is not always known first, then discovered later]
15:50:24 <ora> ack ora
15:50:25 <tl> q?
15:50:30 <tl> q+
15:50:32 <pchampin> ... I hope this use-case can be handled by using RDF-star annotations.
15:51:15 <pchampin> q+
15:51:50 <pchampin> ora: pfps, can you explain the issue you raised with marriages?
15:52:31 <pchampin> pfps: assume you first represented marriages as (groom -maried-> bride), which you birther annotated with location, date, etc.
15:52:52 <Souri> q+
15:53:03 <pchampin> ... but then you realize that you got it wrong, and that they should be represented (groom -marriedIn-> location), annotated with the bride, date, etc.
15:53:16 <pchampin> ... *Then* you need to rewrite your queries.
15:53:16 <TallTed> s/birther/later/
15:53:28 <ora> ack tl
15:53:53 <pchampin> ora: I think everyone expect they need to change their queries if they change their data model.
15:54:38 <niklasl> q+
15:54:38 <pchampin> tl: there is no way to completely avoid remodeling forever ; but RDF-star gives more leeway
15:55:18 <pchampin> q-
15:56:15 <pchampin> ... Yes, RDF is simple, but it is too simple.
15:56:29 <pfps> RDF does *not* require the use of blank nodes for reification.
15:56:40 <pchampin> ... The popularity of PGs comes from the trade-off they made between simplicity and expressivity.
15:56:54 <ora> ack Souri
15:57:53 <pchampin> Souri: with relational data, people will never change the schema from the ground up,
15:58:05 <pchampin> ... but they would add new columns
15:58:51 <pfps> Changes to an RDB schema do actually change the results of some queries!  Consider SELECT * in SQL.  Please don't make RDBs better than they actually are.
15:58:58 <pchampin> ... The popularity of PGs comes from edge properties. It makes extending the data easier.
15:59:49 <pchampin> ... This is the main reason. There are other (complexity of IRIs, scalar values vs. literals).
15:59:51 <tl> q+
15:59:56 <ora> ack niklasl
16:01:10 <pchampin> niklasl: I agree with tl. Shorthand properties and triple annotations are @@1.
16:02:25 <pchampin> ... With RDF-star annotations / marginalia, you can extend your model for a while.
16:02:43 <pchampin> ... [discussion about marriages ending, needing to remove the asserted triple]
16:02:57 <Souri> SELECT * is convenient for development but heavily discouraged in production code. :-)
16:03:00 <AndyS> q?
16:03:20 <AndyS> ack tl
16:04:14 <pchampin> tl: in PGs, there are two levels (properties and relations), while RDF only has triples. RDF is less readable.
16:04:43 <pchampin> ... Properties and relations are different primitives when you model your domain.
16:05:17 <Souri> q+
16:05:30 <pchampin> ... We need to explain how to use RDF-star to model PGs.
16:05:35 <pfps> I find LPGs much less readable.   Maybe this is simply familiarity, but I find the distinction between properties and relations jarring each time I see it.  Of cource, RDF 1.2 would have this same problem.
16:05:37 <TallTed> ack
16:05:47 <AndyS> ack souri
16:06:56 <pchampin> Souri: [discussion about the complexity of SPARQL vs. PG query languages]
16:07:06 <pchampin> ... We need to think about it when extending SPARQL.
16:07:07 <pchampin> q?
16:07:47 <pchampin> gkellogg: what do we want to accomplish?
16:08:18 <pchampin> ... I don't think that RDF-star is a competitor of PGs, but it helps modelling PGs in RDF.
16:08:46 <pchampin> ... The property/relation dichotomy in PGs is confusing for some people (especially with an RDF background):
16:09:00 <pchampin> ... how do you decide which one to use?
16:09:45 <pchampin> present+ enrico
16:10:54 <pchampin> enrico: recent approaches in conceptual modelling do not distinguish between attributes and entities,
16:11:26 <pchampin> ... precisely because it causes problems with data integration.
16:11:38 <pchampin> ... Object Role Modeling is now largely used.
16:11:44 <pchampin> q?
16:13:49 <pchampin> pchampin: [ask enrico about the "birth" example where 'location' and 'date' information is represented redundantly]
16:14:10 <pchampin> enrico: related to databases in the 6th normal form with primary key
16:14:29 <pchampin> ... the primary key is your reification, and everything else is represented with binary relationship.
16:15:34 <pchampin> ... The problem is, in some cases, you don't have an obvious primary key.
16:19:26 <Souri> q+
16:19:32 <pchampin> ... Some database will focus on who is married to whom, another will focus on who was married where.
16:20:28 <pchampin> Souri: this is similar to what I said earlier. Consider birth as a 3-ary relationship (person, location, date)
16:21:12 <pchampin> ... Some people will be interested in the born-in relation, others will be interested in born-on.
16:21:23 <pchampin> ... We need a kind of views.
16:21:48 <tl> q+
16:22:41 <pchampin> enrico: I will not write things like that. But if I alteady have If someone gives me the triple << :b1 | :enrico :born-in :rome >> :on-date 1962 ,
16:23:03 <pchampin> ... and someone sends me << :enrico :born-on 1964 >> :location :rome ,
16:23:17 <pchampin> ... I want to make it clear that they are the same reification.
16:24:24 <pchampin> q?
16:24:33 <pchampin> ack Souri
16:24:35 <pchampin> ack tl
16:25:20 <pchampin> tl: we have to make a decision; do we forbid a Reification to be linked to several triples?
16:26:26 <pchampin> AndyS: I see RDF as a toolbox. I don't think it is for us to say "use it this way or that way".
16:26:31 <niklasl> q+
16:26:55 <pchampin> ... We need to provide the basics.
16:28:10 <pchampin> tl: AndyS, if rdf:reifies is many-to-many , doesn't it raise the same issue as the one you were worried about with rdf:subject, rdf:predicate, rdf:object?
16:28:28 <Souri> q+
16:29:05 <pchampin> AndyS: we want an example that we are all happy with, but that's different from forbidding other things.
16:30:32 <pchampin> RRSAgent, make minutes
16:30:34 <RRSAgent> I have made the request to generate https://www.w3.org/2024/03/01-rdf-star-minutes.html pchampin
16:30:40 <niklasl> :b1 a :Birth .
16:30:52 <niklasl> s/:Birth/ex:Birth/
16:34:29 <niklasl> :b1 a :Birth ; :on-date 1962 ; :location :rome .
16:34:31 <niklasl> :b1 rdf:reifies <<( :enrico :born-in :rome )>>, <<(:enrico :born-on 1962)>> .
16:34:36 <niklasl> :t1 a :Fact ; rdf:reifies <<( :enrico :born-in :rome )>> .
16:35:21 <olaf> q+
16:35:34 <niklasl> :Fact rdfs:subClassOf [ a owl:Restriction ; owl:onProperty rdf:reifies ; owl:cardinality 1 ] .
16:35:34 <Souri> q-
16:36:23 <pchampin> niklasl: I think we don't need to make a choice. This depends on use-cases.
16:36:42 <pchampin> ... In the examples above, :Birth can reify several triples, but :Fact would allow only noe.
16:36:48 <pchampin> ack niklasl
16:36:53 <pchampin> ack olaf
16:38:05 <pchampin> olaf: another question to Enrico; you use the same predicate :born-in, once with the person as the subject, once with the reification as the subject
16:38:18 <pchampin> ... for me that should be two different properties.
16:42:12 <pchampin> RRSAgent, make minutes
16:42:13 <RRSAgent> I have made the request to generate https://www.w3.org/2024/03/01-rdf-star-minutes.html pchampin
16:42:56 <olaf> olaf has left #rdf-star
16:43:29 <pchampin> Zakim, bye
16:43:29 <Zakim> leaving.  As of this point the attendees have been Souri, pchampin, tl, ora, gkellogg, TallTed, niklasl, AndyS, pfps, doerthe, enrico
16:43:29 <Zakim> Zakim has left #rdf-star
16:43:33 <pchampin> RRSAgent, bye
16:43:33 <RRSAgent> I see no action items