Meeting minutes
enrico: I prepared 3 slides to summarize what I can live with.
… 1 slide per profile.
(presenting slides)
Discuss if a single id can reify more than one triple
enrico: profile 1: many-to-many.
… syntax already discussed. unrestricted sytnax.
… semantics treats triple term as resources depending on interpretation of its 3 arguments.
… interesting bit is simple entailment doesn't need to change much. matching still works. simple entailment based on matching.
… extend matching over triple terms, but still just matching.
… profile 2: many-to-one transparent. additional restriction on rdf:reifies to be functional.
… triple terms denote resources based on 3 components.
… additional restriction on rdf:reifies. syntactic restriction.
… entailment not based on graph matching. simple entailment is not the basis for BGP matching.
… bad for merge and data integration because different ids could be many-to-one by different users, but after merging ... different URIs.
… profile 2-opaque: many-to-one opaque. solves issue of entailments.
… triple terms are interpreted as a canonical literal.
… not based on graph matching.
enrico: profile 2-joke: many-to-one.
ora: serious food for thought.
… We've had internal meetings on this. The thing that troubles us is not wanting to stand in the way of progress.
… Are these slides available?
… Send pdf to the mailing list.
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?
enrico: SHACL profile can only restrict the syntax, so profile 2-joke, I think.
… SHACL would restrict shape, but language itself would still have the semantics. Either there's a functional restriction or not.
<niklasl> An OWL restriction can semantically restrict a specific class, for specific uses.
<niklasl> ex:Statement rdfs:subClassOf [ a owl:Restriction ; owl:onProperty rdf:reifies ; owl:cardinality 1 ] .
ora: Given your profile 1 and 2-joke, what do people think if we deal with this as a best practice issue?
<niklasl> <s> :p <o> {| a ex:Statement ; :timestampMills 1714060073 |} .
enrico: I would support this strongly.
… idea would be to have several cases that you could cover with RDF 1.2 many-to-many.
… you can represent LPG and other cases with these semantics. This is not directly reflected by entailment in queries.
… this does not effect your application.
ora: Once we mix LPGs into this, entailment becomes weird anyways.
<niklasl> (also, with :timestampMillis rdfs:domain ex:Statement, explicitly typing the reifier is not necessary)
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.
… if you don't enforce functionality in the algorithm, that's not what you expect.
ora: Understood. Shouldn't ask LPG people about entailment.
pfps: The idea of profiles is to do something useful. What's the utility here?
… 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.
… 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.
… the provenance use case, e.g. With the many-to-many reification, you get a lot fewer triples.
<niklasl> +1
ora: Appreciate what Enrico did. The thing that has worried us is the whole question of entailment.
… We need to have more internal discussions.
… 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.
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?
… Can we have 1 and 3?
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.
… only to point out that whatever you choose, profile-2 has some consequences.
… you will not get rid of consequences.
… I would prefer 2-opaque. This characterises what you really want.
… For DB, you really want to have the full opacity.
… I would be fine with that. Strong decision. At least the standard would not be ambiguous.
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...?
enrico: this would be silly. If you support profile-3, you get profile-1 support for free.
… 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.
… it will also work with profile-1.
<niklasl> Only profile 1 would be real RDF 1.2. The other things would be ... something else ...
enrico: So yes you can, but I don't see it happening in reality.
tl: Can we have a sub-property of reifies that follows a different profile?
… rdf:edgeOf that is opaque or many-to-one semantics?
… syntactically enforce via shacl constraint...
<niklasl> ex:edgeOf a owl:FunctionalProperty ; rdfs:subPropertyOf rdf:reifies .
tl: you could guarantee that if somebody uses edgeOf property, expected to follow many-to-one rules.
… would that be possible? to constrain profile on a specific property?
enrico: yes. interesting way to sell a profile. you still have to have a semantics and implementation for it.
<niklasl> It's just "using RDF with OWL".
enrico: if you want to go with BP and use-cases, we can standardize an rdf property which is meant for BP.
… not part of the proper standard, just part of the BP.
… you can do edges with PGs, you can, but you have to live with unwanted consequences.
<niklasl> Cf. The informal restriction on skos:prefLabel in SKOS (one per language).
enrico: you have to emphasize that this is open.
tl: how open?
enrico: completely.
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?
… If I voluntarily only reify one triple, at which point does that break?
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.
… it's just a profile-1 graph.
… your engine is an option 1 engine for SPARQL entailment, even if you are strict, queries may have unexpected meaning.
Souri: if you start out with many-to-one only, how could it move to many-to-many, I see 3 ways:
… 1) you create such things; 2) if you actually use entailment
ora: now we're in OWL domain?
Souri: 3) via merge
… those are the 3 ways I see you can end up with many-to-many.
<enrico> :e rdf:reifies <<( :s1 :p1 :o1 )>> .
<enrico> :e rdf:reifies <<( :s2 :p2 :o2 )>> .
<enrico> :s1 :p1 :o1 .
<enrico> ASK WHERE { _:x rdf:reifies <<( :s1 _:y :o2 )>> } ==> TRUE
Souri: 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.
… My understanding is that if I say somethign about the single reifier, we are saying things about the *set* of triple terms.
… 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.
… Such triple term sets cannot have parallel edges.
… Those are the restrictions on many-to-many that would arise.
… I don't have strong opinion about which way to go. I like the idea that tl just said.
… 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.
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.
… it depends on how the system works. As pfps has said, you should not even put the entailed data into the same graph.
… relies on expectation that the system has multiple graphs which LPGs don't.
… I wouldn't worry to much about it.
… On merge or user-error would multiple reifiers be added. Could be added if you had an IFP on the reifier itself.
… That's a regular semantic error. Have to work pretty hard to mess up reifiers to go from one to two reifiers.
… Valid use-case. If you have a type like Statement. You're expected to use one reifier on that.
… You could control via SHACL or app specific code.
… many-to-many case does not preclude the many-to-one case.
… a lot of functional properties out there. you can use them incorrectly, too.
… 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.
… reifiers with many-to-many are not graphs. Graphs are more than just two things. They are closed sets.
ora: why a closed set?
niklasl: doesn't have to be closed, but named graphs are thought of as closed in databases.
… 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.
… 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.
olaf: Based on what others are saying, I want to understand better profile 3.
… 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?
enrico: probably not because simple entailment you don't have equality. In SPARQL it may be enforced.
… I'm not sure. Maybe profile 2-opaque is not so badly behaving implementation-wise.
… We cannot enforce equality over literals. This may simplify things.
… We can have a profile which is fully opaque and functional.
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.
… my view: on top of the grammar, we can define different constraints. Is your understanding based only on grammar?
enrico: grammar with semantic constraints is still a grammar. Same thing.
… grammar has semantic condtiions that you can check. Up front you can tell if the graph is well formed.
olaf: not semantic restrictions. syntactic.
enrico: if you want to define a profile, a compiler should be able to tell if you belong to that profile or not.
… people have different understanding on how the fragments should behave. there should be a notion of a syntactic fragment.
olaf: my understanding is that you can also have some that you cannot express in the grammar.
enrico: can be context dependent but still a grammar.
… you can still have a grammar in the sense of a compiler that rejects based on some condition.
olaf: Related to tl's new predicate subproperty of rdf:reifies, carrying meaning of making things opaque.
tl: didn't have a decision if it would mean opaque or not.
<niklasl> Defined as a owl:FunctionalProperty would mean semantic restriction (all triples would denote same relation).
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?
… does it have to be the other way around?
enrico: profile-1 with OWL can do all of this.
… if you add subproperties, then you need OWL to say new property is functional.
… if you have bijection between triples in canonical form, in OWL you have to say they are disjoint.
… I can emulate in profile 1 the edge with opacity and many-to-one.
<AndyS> Profile 3 = Profile 2-opaque (many-to-one)
enrico: 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.
ora: Thoughts?
<niklasl> +1 too
AndyS: earlier, olaf talked abotu a vendor with engine with a profile. Can you write an engine that is profile-neutral?
… want engine to support different data, different usages.
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.
… same engine would work for all these things. after discussion, this engine would be sound for profile-2.
… it would miss some answers, but all given answers would be good for profile 2.
… you'd miss some inferences and query answers.
… because this engine would be sound but incomplete for LPG queries, you might be happy with that.
ora: are we having a semantics call tomorrow?
enrico: yes.
AndyS: subject?
enrico: maybe distinction between profiles.
ora: I'd like to continue that. Will be there tomorrow.
Souri: I agree with what AndyS said. THere will be different use-cases.
… some people will just need LPG semantics. Some need to create multiple triple-terms under the same (reifier).
… can optimize how we process query based on difference.
… how people use these things to model, we don't know. Profile-1 will be used, but don't know how many/what percentage.
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.
… optimally, all engines will be agnostic.
… using a query hint to change on the fly or something like that.
… 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.
… it makes a difference.
… based on owl:sameAs data out in the world.
… will bite people if engine cannot change on the fly based on query or data that is in play.
AndyS: clarification: you reference option 3 wiki page. which of those abstract syntaxes do you mean?
enrico: in a sense both.
<tl> TallTed attaching "profiles" to specific properties might help against messing things up
enrico: first one is what everyone wants anyway. well-formed syntax would match all the profiles.
AndyS: unrestricted rdf data model?
enrico: to be fair, I don't like it.
AndyS: my understanding of profiles, choices users can make.
… underlying definitions will have to be general.
enrico: proposal: no profiles. rdf:reifies property many-to-many. subproperty rdf:edge which is meant to capture many-to-one.
… 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.
… no problem of recognizing profiles.
… profiles are problemantic because syntactically they look the same.
… if we differentiate the properties, then we can say it's still option-1 (unrestricted), but optionally implementors decide.
<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).
sorry Andy, just dropped. was that a question for me?
<AndyS> No Q - hard scribing - should count x2 !