15:58:11 <RRSAgent> RRSAgent has joined #rdf-star
15:58:15 <RRSAgent> logging to https://www.w3.org/2024/04/25-rdf-star-irc
15:58:15 <TallTed> TallTed has joined #rdf-star
15:58:35 <tl> tl has joined #rdf-star
15:58:35 <ktk> meeting: RDF-star WG biweekly focused meeting
15:58:49 <pfps> pfps has joined #rdf-star
15:58:54 <ktk> Agenda: https://www.w3.org/events/meetings/5ecc5c5f-5cd2-410c-b97c-6b13c6b843f1/20240425T120000/
15:58:54 <agendabot> clear agenda
15:58:54 <agendabot> agenda+ Discuss if a single id can reify more than one triple
15:59:22 <ktk> RRSAgent, draft minutes
15:59:23 <RRSAgent> I have made the request to generate https://www.w3.org/2024/04/25-rdf-star-minutes.html ktk
15:59:26 <AndyS> AndyS has joined #rdf-star
15:59:28 <ktk> RRSAgent, make log public
15:59:36 <enrico> enrico has joined #rdf-star
15:59:42 <enrico> present+
15:59:42 <olaf> olaf has joined #rdf-star
16:00:06 <ktk> present+
16:00:07 <AndyS> present+
16:00:11 <gtw> present+
16:00:20 <gtw> scribe: gtw
16:01:04 <ktk> Regrets+ gkellog, darndt Dominik_T
16:01:08 <eBremer> eBremer has joined #rdf-star
16:01:29 <fsasaki> present+
16:01:29 <ktk> s/darndt Dominik_T/darndt, Dominik_T/
16:01:29 <ora> ora has joined #rdf-star
16:01:31 <olaf> present+
16:01:31 <TallTed> present+
16:01:43 <ora> present+
16:01:49 <ora> chair: ora
16:02:11 <ktk> RRSAgent, draft minutes
16:02:12 <RRSAgent> I have made the request to generate https://www.w3.org/2024/04/25-rdf-star-minutes.html ktk
16:02:18 <AZ> present+
16:02:42 <AndyS> AndyS has changed the topic to: RDF-star WG - 2024-04-25
16:02:51 <enrico> q+
16:03:04 <ora> ack enrico
16:03:17 <gtw> enrico: I prepared 3 slides to summarize what I can live with.
16:03:27 <gtw> ... 1 slide per profile.
16:04:07 <gtw> (presenting slides)
16:04:11 <TallTed> Zakim, next item
16:04:11 <Zakim> agendum 1 -- Discuss if a single id can reify more than one triple -- taken up [from agendabot]
16:04:20 <gtw> enrico: profile 1: many-to-many.
16:04:39 <gtw> ... syntax already discussed. unrestricted sytnax.
16:04:43 <AndyS> AndyS has changed the topic to: RDF-star WG - 2024-04-25 -- https://www.w3.org/events/meetings/5ecc5c5f-5cd2-410c-b97c-6b13c6b843f1/20240425T120000/
16:05:03 <gtw> ... semantics treats triple term as resources depending on interpretation of its 3 arguments.
16:05:05 <niklasl> niklasl has joined #rdf-star
16:05:06 <eBremer> present+
16:05:16 <niklasl> present+
16:05:31 <gtw> ... interesting bit is simple entailment doesn't need to change much. matching still works. simple entailment based on matching.
16:05:50 <gtw> ... extend matching over triple terms, but still just matching.
16:06:17 <gtw> ... profile 2: many-to-one transparent. additional restriction on rdf:reifies to be functional.
16:06:39 <gtw> ... triple terms denote resources based on 3 components.
16:06:58 <gtw> ... additional restriction on rdf:reifies. syntactic restriction.
16:07:37 <gtw> ... entailment not based on graph matching. simple entailment is not the basis for BGP matching.
16:08:19 <gtw> ... bad for merge and data integration because different ids could be many-to-one by different users, but after merging ... different URIs.
16:08:38 <gtw> ... profile 3: many-to-one opaque. solves issue of entailments.
16:08:45 <gtw> ... triple terms are interpreted as a canonical literal.
16:08:57 <gtw> ... not based on graph matching.
16:09:27 <gtw> s/profile 3/profile 2-opaque/
16:10:04 <gtw> enrico: profile 2-joke: many-to-one.
16:10:06 <ora> q?
16:10:27 <gtw> ora: serious food for thought.
16:10:44 <gtw> ... We've had internal meetings on this. The thing that troubles us is not wanting to stand in the way of progress.
16:10:54 <gtw> ... Are these slides available?
16:11:02 <Souri> Souri has joined #rdf-star
16:11:03 <tl> q+
16:11:07 <gtw> ... Send pdf to the mailing list.
16:11:11 <Souri> present+
16:11:16 <ora> ack tl
16:11:39 <gtw> tl: Question - if we had document on best practices for reification having only one object (many-to-one), adding SHACL constraing for enforcement, which profile would that map to?
16:11:59 <gtw> enrico: SHACL profile can only restrict the syntax, so profile 2-joke, I think.
16:12:04 <ora> q+
16:12:24 <gtw> ... SHACL would restrict shape, but language itself would still have the semantics. Either there's a functional restriction or not.
16:12:26 <ora> ack ora
16:12:32 <niklasl> An OWL restriction can semantically restrict a specific class, for specific uses.
16:13:08 <niklasl> ex:Statement rdfs:subClassOf [ a owl:Restriction ; owl:onProperty rdf:reifies ; owl:cardinality 1 ] .
16:13:09 <gtw> ora: Given your profile 1 and 2-joke, what do people think if we deal with this as a best practice issue?
16:13:09 <niklasl> <s> :p <o> {| a ex:Statement ; :timestampMills 1714060073 |} .
16:13:24 <gtw> enrico: I would support this strongly.
16:13:26 <pfps> q+
16:13:42 <gtw> ... idea would be to have several cases that you could cover with RDF 1.2 many-to-many.
16:14:01 <gtw> ... you can represent LPG and other cases with these semantics. This is not directly reflected by entailment in queries.
16:14:04 <gtw> ... this does not effect your application.
16:14:15 <gtw> ora: Once we mix LPGs into this, entailment becomes weird anyways.
16:14:42 <niklasl> (also, with :timestampMillis rdfs:domain ex:Statement, explicitly typing the reifier is not necessary)
16:14:44 <gtw> enrico: Queries have a quality. I can craft a query (SPARQL, OC, ...) in which I enforce the quality by using the symbol in multiple places.
16:14:55 <gtw> ... if you don't enforce functionality in the algorithm, that's not what you expect.
16:15:17 <gtw> ora: Understood. Shouldn't ask LPG people about entailment.
16:15:23 <ora> ack pfps
16:15:51 <gtw> pfps: The idea of profiles is to do something useful. What's the utility here?
16:16:08 <gtw> ... I'm trying to get somethign I can believe that has any utility whatsoever for restricting. I'm not hearing anythign I find positive about this restriction.
16:16:31 <gtw> ... as far as use cases go, sure let's take the use cases we've got and add some and create a document saying here's how you might use this thign we're adding to RDF.
16:16:49 <gtw> ... the provenance use case, e.g. With the many-to-many reification, you get a lot fewer triples.
16:17:02 <niklasl> +1
16:17:53 <gtw> ora: Appreciate what Enrico did. The thing that has worried us is the whole question of entailment.
16:18:13 <gtw> ... We need to have more internal discussions.
16:18:55 <gtw> ... Speaking as myself (not chair or AWS), I really like the way you formulated these things. It would be easy to buy the profile-1.
16:19:00 <olaf> q+
16:19:06 <ora> ack olaf
16:19:16 <Kurt> Kurt has joined #rdf-star
16:19:22 <gtw> olaf: I want to understand better: is the idea that we can have multiple of these profiles? Or you are presenting them and we have to pick one?
16:19:28 <gtw> ... Can we have 1 and 3?
16:19:44 <tl> q+
16:20:04 <gtw> enrico: I don't care. What' I'm saying is we can have 2 profiles or 3. Whatever you want. I prefer 1 with use cases.
16:20:16 <gtw> ... only to point out that whatever you choose, profile-2 has some consequences.
16:20:27 <gtw> ... you will not get rid of consequences.
16:20:48 <gtw> ... I would prefer 2-opaque. This characterises what you really want.
16:21:02 <gtw> ... For DB, you really want to have the full opacity.
16:21:14 <gtw> ... I would be fine with that. Strong decision. At least the standard would not be ambiguous.
16:21:47 <gtw> olaf: If we have both of these profiles, a vendor can decide that "my system supports profile-3" meaning if I read in any data that violates syntactic restirctions, I'm just giving an error message...?
16:22:00 <gtw> enrico: this would be silly. If you support profile-3, you get profile-1 support for free.
16:22:50 <gtw> ... RDF option-3 could map to LPG for those who don't care about RDF. If you have an engine supporting profile 3, then it is a very complex implementation.
16:23:00 <gtw> ... it will also work with profile-1.
16:23:03 <niklasl> Only profile 1 would be real RDF 1.2. The other things would be ... something else ...
16:23:09 <ora> ack tl
16:23:10 <gtw> ... So yes you can, but I don't see it happening in reality.
16:23:21 <gtw> tl: Can we have a sub-property of reifies that follows a different profile?
16:23:33 <gtw> ... rdf:edgeOf that is opaque or many-to-one semantics?
16:23:39 <gtw> ... syntactically enforce via shacl constraint...
16:23:52 <niklasl> ex:edgeOf a owl:FunctionalProperty ; rdfs:subPropertyOf rdf:reifies .
16:23:52 <gtw> ... you could guarantee that if somebody uses edgeOf property, expected to follow many-to-one rules.
16:24:07 <gtw> ... would that be possible? to constrain profile on a specific property?
16:24:20 <gtw> enrico: yes. interesting way to sell a profile. you still have to have a semantics and implementation for it.
16:24:27 <niklasl> It's just "using RDF with OWL".
16:24:40 <gtw> ... if you want to go with BP and use-cases, we can standardize an rdf property which is meant for BP.
16:24:46 <ora> q+
16:24:49 <gtw> ... not part of the proper standard, just part of the BP.
16:25:13 <gtw> ... you can do edges with PGs, you can, but you have to live with unwanted consequences.
16:25:23 <ora> ack ora
16:25:23 <niklasl> Cf. The informal restriction on skos:prefLabel in SKOS (one per language).
16:25:23 <gtw> ... you have to emphasize that this is open.
16:25:28 <gtw> tl: how open?
16:25:31 <gtw> enrico: completely.
16:26:17 <gtw> ora: I want to understand, if I started out in this subset where I only use reifier for a single triple, under what conditions am I taken out of that subset to where reification reifies multiple triples?
16:26:33 <gtw> ... If I voluntarily only reify one triple, at which point does that break?
16:26:38 <Souri> q+
16:27:11 <niklasl> q+
16:27:12 <gtw> enrico: If you strictly enforce syntactically "correct" data for your edge properties, does not forbid anybody from writing a query where you get unexpectred results.
16:27:38 <gtw> ... it's just a profile-1 graph.
16:28:01 <gtw> ... your engine is an option 1 engine for SPARQL entailment, even if you are strict, queries may have unexpected meaning.
16:28:25 <ora> ack Souri
16:28:45 <gtw> Souri: if you start out with many-to-one only, how could it move to many-to-many, I see 3 ways:
16:29:09 <gtw> ... 1) you create such things; 2) if you actually use entailment
16:29:15 <gtw> ora: now we're in OWL domain?
16:29:51 <gtw> Souri: 3) via merge
16:30:24 <gtw> ... those are the 3 ways I see you can end up with many-to-many.
16:30:44 <enrico> :e rdf:reifies <<( :s1 :p1 :o1 )>> .
16:30:44 <enrico> :e rdf:reifies <<( :s2 :p2 :o2 )>> .
16:30:44 <enrico> :s1 :p1 :o1 .
16:30:53 <enrico> ASK WHERE { _:x rdf:reifies <<( :s1 _:y :o2 )>> }  ==> TRUE
16:31:02 <gtw> ... besides these possibilities, I see many-to-many, you're doing an "edge set". You're saying something about that edge set through the single reifier.
16:31:19 <gtw> ... My understanding is that if I say somethign about the single reifier, we are saying things about the *set* of triple terms.
16:31:40 <gtw> ... If you want to say things about a single triple, cannot have it as part of a set of triple terms with a single reifier.
16:31:52 <gtw> ... Such triple term sets cannot have parallel edges.
16:32:10 <gtw> ... Those are the restrictions on many-to-many that would arise.
16:32:29 <gtw> ... I don't have strong opinion about which way to go. I like the idea that tl just said.
16:32:52 <gtw> ... For supporting, both can be used. Have talked about LPG profile. Would be nice to say this RDF data is validated to convert to LPG.
16:33:12 <ora> ack niklasl
16:33:41 <gtw> niklasl: I think Souri said much of what I wanted to say. I will add that if you have entailment like symmetric properties, you also have to put it back in the graph for it to become a problem.
16:34:01 <gtw> ... it depends on how the system works. As pfps has said, you should not even put the entailed data into the same graph.
16:34:12 <gtw> ... relies on expectation that the system has multiple graphs which LPGs don't.
16:34:17 <gtw> ... I wouldn't worry to much about it.
16:34:36 <gtw> ... On merge or user-error would multiple reifiers be added. Could be added if you had an IFP on the reifier itself.
16:35:07 <gtw> ... That's a regular semantic error. Have to work pretty hard to mess up reifiers to go from one to two reifiers.
16:35:19 <gtw> ... Valid use-case. If you have a type like Statement. You're expected to use one reifier on that.
16:35:30 <gtw> ... You could control via SHACL or app specific code.
16:35:31 <ora> q+
16:35:35 <TallTed> previous meeting: https://www.w3.org/2024/04/19-rdf-star-minutes.html
16:35:36 <TallTed> next meeting: https://www.w3.org/2024/04/26-rdf-star-minutes.html
16:35:40 <TallTed> RRSAgent, draft minutes
16:35:42 <RRSAgent> I have made the request to generate https://www.w3.org/2024/04/25-rdf-star-minutes.html TallTed
16:35:48 <gtw> ... many-to-many case does not preclude the many-to-one case.
16:35:53 <ora> q-
16:35:57 <olaf> q+
16:35:59 <gtw> ... a lot of functional properties out there. you can use them incorrectly, too.
16:36:35 <gtw> ... to the point of the sets, if I know two people, I don't know the set of those. Having two statements does not mean it's a set.
16:36:36 <TallTed> present+ pfps, tl
16:36:47 <gtw> ... reifiers with many-to-many are not graphs. Graphs are more than just two things. They are closed sets.
16:36:55 <gtw> ora: why a closed set?
16:37:07 <gtw> niklasl: doesn't have to be closed, but named graphs are thought of as closed in databases.
16:37:28 <gtw> ... not defined like that. pchampin had an example with list of triples being the more useful way to represent graphs if you had to using triple terms.
16:38:00 <gtw> ... only thing I've heard is the strong position that having to reify two triple terms on the same reifier doesn't mean that is a graph. The reifier isn't necessarily a graph of those triples. Depends on type and interpretation.
16:38:01 <ora> ack olaf
16:38:21 <gtw> olaf: Based on what others are saying, I want to understand better profile 3.
16:38:46 <gtw> ... question: Souri mentioned 3 ways to end up with many-to-many. One fo them is entailment. In context of profile 3, do entailments have an effect?
16:39:05 <gtw> enrico: probably not because simple entailment you don't have equality. In SPARQL it may be enforced.
16:39:20 <gtw> ... I'm not sure. Maybe profile 2-opaque is not so badly behaving implementation-wise.
16:39:47 <gtw> ... We cannot enforce equality over literals. This may simplify things.
16:39:59 <gtw> ... We can have a profile which is fully opaque and functional.
16:40:40 <gtw> olaf: I want to make sure we mean the same thing by "syntactic restrictions." Different grammar? If the grammar is different, you can restrict things by making the grammar more restrictive.
16:41:01 <gtw> ... my view: on top of the grammar, we can define different constraints. Is your understanding based only on grammar?
16:41:13 <gtw> enrico: grammar with semantic constraints is still a grammar. Same thing.
16:41:36 <gtw> ... grammar has semantic condtiions that you can check. Up front you can tell if the graph is well formed.
16:41:43 <gtw> olaf: not semantic restrictions. syntactic.
16:41:59 <gtw> enrico: if you want to define a profile, a compiler should be able to tell if you belong to that profile or not.
16:42:03 <AndyS> RRSAgent, draft minutes
16:42:04 <RRSAgent> I have made the request to generate https://www.w3.org/2024/04/25-rdf-star-minutes.html AndyS
16:42:23 <gtw> ... people have different understanding on how the fragments should behave. there should be a notion of a syntactic fragment.
16:42:38 <gtw> olaf: my understanding is that you can also have some that you cannot express in the grammar.
16:42:38 <AndyS> q+
16:42:49 <gtw> enrico: can be context dependent but still a grammar.
16:43:04 <gtw> ... you can still have a grammar in the sense of a compiler that rejects based on some condition.
16:43:36 <gtw> olaf: Related to tl's new predicate subproperty of rdf:reifies, carrying meaning of making things opaque.
16:43:50 <gtw> tl: didn't have a decision if it would mean opaque or not.
16:44:27 <niklasl> Defined as a owl:FunctionalProperty would mean semantic restriction (all triples would denote same relation).
16:44:28 <gtw> olaf: if we would introduce a new property that captures the idea of profile 3 (2-opaque), can this be a subproperty of the property for which we have many-to-many with transparency?
16:44:32 <gtw> ... does it have to be the other way around?
16:44:41 <gtw> enrico: profile-1 with OWL can do all of this.
16:45:00 <gtw> ... if you add subproperties, then you need OWL to say new property is functional.
16:45:24 <gtw> ... if you have bijection between triples in canonical form, in OWL you have to say they are disjoint.
16:45:36 <gtw> ... I can emulate in profile 1 the edge with opacity and many-to-one.
16:46:05 <AndyS> Profile 3 = Profile 2-opaque (many-to-one)
16:46:07 <AndyS> q-
16:46:47 <gtw> ... If you want to restrict reifier, you dont' need subproperty. rdf:reifies with constraint. If you have a way to write canonical triples, profile-1 is more than enough to talk about profile-1 with opacity.
16:47:06 <gtw> ora: Thoughts?
16:47:25 <niklasl> +1 too
16:47:27 <AndyS> q+
16:47:35 <ora> ack AndyS
16:47:56 <gtw> AndyS: earlier, olaf talked abotu a vendor with engine with a profile. Can you write an engine that is profile-neutral?
16:48:07 <gtw> ... want engine to support different data, different usages.
16:48:46 <gtw> enrico: In our notion of RDF 1.2, this would be the neutral thing. Simple matching works. Profile-1, syntactic restrictions does not effect implementation.
16:49:11 <gtw> ... same engine would work for all these things. after discussion, this engine would be sound for profile-2.
16:49:32 <gtw> ... it would miss some answers, but all given answers would be good for profile 2.
16:49:51 <gtw> ... you'd miss some inferences and query answers.
16:50:05 <gtw> ... because this engine would be sound but incomplete for LPG queries, you might be happy with that.
16:50:37 <gtw> ora: are we having a semantics call tomorrow?
16:50:40 <gtw> enrico: yes.
16:50:57 <gtw> AndyS: subject?
16:51:05 <gtw> enrico: maybe distinction between profiles.
16:51:13 <gtw> ora: I'd like to continue that. Will be there tomorrow.
16:52:18 <Souri> q+
16:52:37 <ora> ack Souri
16:52:41 <gtw> Souri: I agree with what AndyS said. THere will be different use-cases.
16:53:00 <TallTed> q+
16:53:04 <gtw> ... some people will just need LPG semantics. Some need to create multiple triple-terms under the same (reifier).
16:53:18 <gtw> ... can optimize how we process query based on difference.
16:53:58 <ora> ack TallTed
16:54:00 <gtw> ... how people use these things to model, we don't know. Profile-1 will be used, but don't know how many/what percentage.
16:54:21 <gtw> TallTed: I think we'll find quickly people think they're going to use one profile, then a query or dataset surfaces that uses a different profile and they'll need to mix them.
16:54:26 <AndyS> q+
16:54:29 <gtw> ... optimally, all engines will be agnostic.
16:54:36 <gtw> ... using a query hint to change on the fly or something like that.
16:54:51 <enrico> q+
16:54:54 <gtw> ... in Virtuoso, ability to turn on and off owl/rdfs profiles so you can have owl:sameAs active or not active for a given query.
16:55:03 <gtw> ... it makes a difference.
16:55:14 <gtw> ... based on owl:sameAs data out in the world.
16:55:26 <gtw> ... will bite people if engine cannot change on the fly based on query or data that is in play.
16:55:26 <ora> ack AndyS
16:55:44 <gtw> AndyS: clarification: you reference option 3 wiki page. which of those abstract syntaxes do you mean?
16:55:48 <gtw> enrico: in a sense both.
16:55:54 <tl> TallTed attaching "profiles" to specific properties might help against messing things up
16:56:01 <gtw> ... first one is what everyone wants anyway. well-formed syntax would match all the profiles.
16:56:09 <gtw> AndyS: unrestricted rdf data model?
16:56:14 <gtw> enrico: to be fair, I don't like it.
16:56:24 <gtw> AndyS: my understanding of profiles, choices users can make.
16:56:31 <gtw> ... underlying definitions will have to be general.
16:57:20 <gtw> enrico: proposal: no profiles. rdf:reifies property many-to-many. subproperty rdf:edge which is meant to capture many-to-one.
16:58:17 <gtw> ... just one profile. standard RDF style. only allow well-formed grammar. but we don't have profiles. reifies is many-to-many. subproperty rdf:edge is meant to be many-to-one if implementors decide to implement it.
16:58:23 <gtw> ... no problem of recognizing profiles.
16:58:34 <gtw> ... profiles are problemantic because syntactically they look the same.
16:59:01 <gtw> ... if we differentiate the properties, then we can say it's still option-1 (unrestricted), but optionally implementors decide.
16:59:11 <tl> q+
16:59:23 <tl> q-
16:59:27 <niklasl> For the record: I would only approve of triples as subjects if literals are. And then still thoroughly prevent that from being unknowingly used (I bet 99.9% of use cases do without those *primitives* as subject).
16:59:29 <TallTed> RRSAgent, draft minutes
16:59:30 <RRSAgent> I have made the request to generate https://www.w3.org/2024/04/25-rdf-star-minutes.html TallTed
17:00:11 <gtw> sorry Andy, just dropped. was that a question for me?
17:00:29 <olaf> olaf has left #rdf-star
17:00:41 <AndyS> No Q - hard scribing - should count x2  !
17:15:48 <TallTed> Zakim, end meeting
17:15:48 <Zakim> As of this point the attendees have been enrico, ktk, AndyS, gtw, fsasaki, olaf, TallTed, ora, AZ, eBremer, niklasl, Souri, pfps, tl
17:15:48 <Zakim> RRSAgent, please draft minutes
17:15:49 <RRSAgent> I have made the request to generate https://www.w3.org/2024/04/25-rdf-star-minutes.html Zakim
17:15:55 <Zakim> I am happy to have been of service, TallTed; please remember to excuse RRSAgent.  Goodbye
17:15:55 <Zakim> Zakim has left #rdf-star
17:16:00 <TallTed> RRSAgent, bye
17:16:00 <RRSAgent> I see no action items