Meeting minutes
Continuing discussion: is rdf:reifies functional or not?
<pchampin> hi all, I will be ~30 minutes late, apologies
tl: can LPG object attributes be annotated?
<doerthe> yes souri said
Souri: true
Souri: lots of differences between LPGs and RDF; attributes is one. The edge has the same restriction (cannot link edges).
… but RDF lacks the edge property feature
… but we obviously cannot restrict RDF 1.2 to what LPGs do
… I completely agree on many-to-many, but I see two shortcomings; one reifier for two terms, but I may still want to have describe triple terms. Also, do statements about a "to-many" reifier apply to each, or to the reifier
… overall, many-to-many is fine, but we need to adress and document handling for these shortcomings
doerthe: [aside] any good introduction to LPGs?
enrico: there is a new guide to the upcoming LPG standard (the GQL standard arrived yesterday - 600 pages)
doerthe: the only way to make the many-to-one relationship is to go back to referential opacity
… we can define a property graph shape to define the LPG restrictions
<enrico> The paper summarising LPGs: https://
<doerthe> thank you enrico
<Souri> From my earlier posting:
<Souri> Following are some of the issues I see with multi-valued (i.e., many-to-many) rdf:reifies:
<Souri> 1) a single reifier cannot associate with two identical triple-terms (needed for parallel edges), and
<Souri> 2) creates a confusion regarding whether the annotations hanging from the single reifier applies to every triple-term individually or only to the set of triple-terms as a whole.
<Souri> My feeling is that It is important to be able to be able to hang annotations independently:
<Souri> 1) to individual triple-terms, and
<Souri> 2) to a mutli-set of triple-terms as a whole.
<pchampin> +1
enrico: there is a confusion between the reifier and the triple term
… the same triple can be reified in many ways, both as a marriage or the utterance of the triple
… in either case, you attach the property to the *reifier*
… in the case of a many-to-one edge annotation, create a new reifier for that
<doerthe> problem could be that this is not closed? Not sure
enrico: "John married Sue; *it* happened in May; and *it* was said yesterday". The *it* here are two different reifiers, with different types and different properties.
tl: If you have a reifier for many triples and you want to say more about one of those, do you have to rewrite your queries?
… can we reify reifiers?
… to speak about all three reifers?
<doerthe> but why? I could also do that more directly
<niklasl> Agreed (I i think)
<niklasl> (agreed with Dörthe)
pchampin: Something niklasl said, how do I know that the triple is reified by the marriage?
… you can reifiy the statement twice, once as a marriage and once as a statement
<niklasl> Yes, exactly.
<niklasl> declare rdfs:domain on the properties you describe reifiers with and you don't have to type them explicitly.
Souri: a document has sentences, paragrapghs, sections, chapters I think of these [...] as a paragraph.
… we can have a sequence of sentences. I want to speak about each sentence, and also about the paragraph itself.
… And model that using RDF.
… with a collection of sentences as a paragraph [...] I lose the ability to talk about each sentence. With a member relationship I can have each sentence and the paragraph as a [ordered] collection of those
<TallTed> RDF is pretty far removed from natural language. RDF (especially if you add RDFS and/or OWL) is much closer to first-order-logic.
<niklasl> Yes, and that's OK. But it's *fundamentally* different from the reification of a marriage.
<tl> @Souri of course, but it will in general be considered too cumbersome
+1 to TallTed re. natural language / RDF / first-order-logic
<enrico> -1 to TallTed re NL vs RDF
<tl> @Souri that's why I asked for nesting reifiers, i.e. reifying reifications. that could be done when needed and omitted otherwise
Souri: My motivation is to not lose that ability.
<niklasl> s/that\/that ability./
pchampin: Ora is asking about the many to many case; how to explain this easily.
… I think the right way to explain this is to explain it per reifier type.
… and then we explain "I can do this for that"
… second point; let's not fortitiously use rdf:reifier when we actually *want* a set of reifier.
<tl> so should we define an "rdf:edgeOf" as ubproperty of rdf:reifies, with range cardinality 1 ?
pchampin: Define a paragraph property ex:hasSentence
… let's not pretend everything is related using rdf:reifier
… Also, using many-to-many to represent a graph is not enough, it has inference problems.
https://
[or perhaps wait until an amendment]
<tl> and another subproperty "graphOf"?
<doerthe> (I wanted to complain about the example :D )
enrico: a triple term only denotes itself, not "the statement"
… if sentences are things that you can utter, create a list of those reifiers. The sentences are the reifiers of triples.
<TallTed> s/"s/that\/that ability./"/""/
Souri: When I see a multivalued reifier it seems to create a box (???) ; but perhaps there is a mismatch here?
… a convention to hang from the reifier if it is a box
… I'm quite OK with the many-to-many, I don't see the necessity to explain that to people who only want to do LPG style modelling
<TallTed> s/"s/that\/that ability./"//
pchampin: I still believe in the email I wrote
… to Souri: be careful, the reifier is not really a box; because of the open world assumption
… It *may* reify more triples than what we know of
<niklasl> And that is exactly why it's very problematic if it is functional in any logical sense of functional!
<Souri> agree to: multi-valued (rdf:reifies .., .., .., . ) vs. set-valued (RDF named or default graph)
<Souri> open box :-)
+1
<enrico> or not?
<enrico> (Schrödinger's cat)
tl: how to convert a multi-edge reifier to simple ones?
… do we convert them to a set of LPG reifiers, with a forEach semantics?
<niklasl> I think it's an OK "hack"o to be able to query many-to-many in LPGs
[... missed what clashes between tl:s and enrico:s examples]
doerthe: there is no negation, so they could have loved each other before [their mutual love]
pfps: about the restrictive implications: very problematic [...]
<tl> how do we translate a multi-edge annotation to LPG? is it safe to convert them to (necessarily single edge) LPG edges all with the same annotations, effectively applying a for-each-semantics? i think it is, but i haven't heard other opinions. also it somehow collides with the intuition that a reifier is an entity on its own, not a set of abstract
<tl> triples.
<Zakim> pchampin, you wanted to respond to tl about "distributive" properties
pchampin: you can't have your cake and eat it. If a property has a domain of Person, you cant put it on a set of persons. But if the domain *is* ListOfPersons, you can have semantics for that. A proerty like :nameForEach .
<niklasl> ex:nameForEach owl:propertyChainAxiom (ex:memberOfList ex:name) .
pchampin: the property on a Wedding is on the wedding. You *might* think of it as a [shorthand]
<enrico> to see how to express distributive properties in the context of a language like RDF (it was description logics), see my very old paper https://
<niklasl> that's what I try to illustrate by e.g. :reifiesSubject rdfs:subPropertyOf meta:implicates; owl:propertyChainAxiom (rdf:reifies rdf:subject) .
fsasaki: To Souri: With different RDF data producers. If some of these has a one-to-many, can you merge these easily? Or if you want to cross-query across datasets in the opposite, case, how would that work?
… Ora is talking about cross-queries
Souri: if you have many-to-one in two graphs with the same reifier and merge them; the same reifier basically become two reifiers [?] ; if you query that, we mark the dataset and if we don't want it to be multi-valued we raise a validation error.
fsasaki: so you're stuck with validation errors, and the users have no easy way to fix that?
Souri: if you require such validation; but we don't enforce such validation, if the user don't want to restrict to many-to-one we can handle it
fsasaki: but then the user must update the data?
Souri: we don't interpret their data, it's their business. If its invalid to them we just raise that.
enrico: There's been a lot of work many years ago, how to add generalized quantifiers to the abox. For each in the group, etc. Natural language about multiple entites ("Tom, Dick and Harry each ate a pizza", how many pizzas were eaten?, They carried a piano, etc.)
… see my link above (my 30 year old paper)
<doerthe> just for the record: properties in NL are not necessary binary. "It rains"? "Paul gives Mary the book"?
<enrico> Paul gives TO Mary the book
pchampin: If two people are using many-to-one and reify different triples for the same wedding, we can't in general require the functional restriction.
<niklasl> but my pipe example was inspired by the very much too simple example 2 in https://
pchampin: the many-to-many is not a useful pattern to start with, but it may be necessary for data integration
+1 to that
… If you put the same reifier on multiple triples, probably you have an n-ary relation, and here is how to handle that
<doerthe> The to comes from your native language. but let's stick to rain, in linguistics I learned that this is considered 0-ary
<enrico> Unary relations are fine
<niklasl> but meanwhile, group them to the reifier
<fsasaki> for the record, my question was triggered not only by the modeling aspect of data integration but by the workflow aspect. I am thinking of different data producers who use different modeling patterns, leading to issues discovered by a data consumers, and then the need to fix the errors again by the data producers. My impression is that many-to-many will
<fsasaki> lead to more such process cycles needed.
AndyS: Pierre-Antoine touched on this - if you look at Bryan's example; given any LPG example, it can be automatically translated to RDF. Thomas also mentioned that in looking at the relationship between the two, there are two subproblems, going from the one to the other, and vice versa.
… If the explanation becomes very abstract and can't readily be automatic, it can change the perception of what we're doing
enrico: the killer application of RDF has always been data integration
<doerthe> there are predicates which cannot exist in a binary way. "Enrico gives book" is not a valid sentence in English (and yet, my example does not work, Enrico could give love :D, but there are predicates like that)
enrico: and a colleague of mine recently submitted a use case exactly on the line of the wedding
<Zakim> enrico, you wanted to comment on data integration
<TallTed> "model it properly" is a slippery slope. "proper" changes over time, with different perspective and/or observer.
<enrico> +1 TallTed
Agreed, TallTed! I think I put it too strongly. Thomas is softening it I think.
Caring for the generally expected, flat and simple case, and adding a "maginalia" model in up front is *also* a valid usage pattern! Just not well-known in the RDF world.
(Right now of course, I see it everywhere in my daily work. Wearing RDF-star-colored glasses.)