Aw: multisets everywhere

Dear Thomas,

Here is my mail again since I just noticed that I forgot to include the group.
I hope it is still readable.



I did not manage to answer your mail before my Christmas holidays (sorry for that and happy new year!) and now the thread got so long that I did not dare to answer (hopefully all smart things are already said ;)). Nevertheless, I will try now (with the disclaimer that I did not read all of the answers, so I might repeat what other have said):

In general, I see RDF as a language in which you can express knowledge just like natural language (but hopefully with a less ambiguous semantics). You can make statements and if you make them, I expect that you think (or want me to think) that they are true. In that sense RDF is very simple but also very powerful. We can state something and that has a meaning.

With your proposal (if I understand it correctly), you change that meaning and this is what I consider problematic. I try to explain below (and also answer your questions).

Am 20.12.2021 um 16:40 schrieb thomas lörtsch <tl@rat.io<mailto:tl@rat.io>>:



Am 20.12.2021 um 15:19 schrieb Doerthe Arndt <doerthe.arndt@tu-dresden.de<mailto:doerthe.arndt@tu-dresden.de>>:

Dear Thomas,

Am 20.12.2021 um 14:32 schrieb thomas lörtsch <tl@rat.io<mailto:tl@rat.io>>:



Am 20. Dezember 2021 11:47:48 MEZ schrieb Doerthe Arndt <doerthe.arndt@tu-dresden.de<mailto:doerthe.arndt@tu-dresden.de>>:
Dear Thomas,

Before going into full discussion mode again :), I would like to fully understand your proposal, so please allow me one question:

Why do you go for

:Alice :plays :Guitar .
[] :occurrenceOf <<:Alice :plays :Guitar>> ;
  :mood :Happy.
[] :occurrenceOf <<:Alice :plays :Guitar>> ;
  :mood :Moody .

According to RDF semantics  „:Alice :plays :Guitar .“  is a statement which can be true or false (we normally assume that it is true if you state it). If you add triples, this one statement should not change its meaning (monotonicity). But here, it does.

If we write:

:Alice :plays :Guitar .
[] :occurrenceOf <<:Alice :plays :Guitar>> ;
 :stop 2021.

We added some triples (namely [] :occurrenceOf <<:Alice :plays :Guitar>> ; :stop 2021.) which made that our original triple is not true any more.

This is in my opinion very problematic. No only from a logical point of view, but also in a very practical sense: You cannot extract simple triples from your graph anymore to work with (make derivations, answer queries, etc.) but you will always have to consider their context (are there triples which make them invalid?). These context checks can get very complicated and in that sense you are creating monster here :).


instead of

[] :occurrenceOf <<:Alice :plays :Guitar>> ;
  :mood :Happy.
[] :occurrenceOf <<:Alice :plays :Guitar>> ;
  :mood :Moody .


with your short cut?
I am asking because especially with the marriedTo example looks to me like a case where the statement changes its truth value over time (i.e. the triple becomes false if the marriage ends, or could at least become false depending on what „:marriedTo“ means).

Maybe I simply missed that point in your previous explanations, so is there a short answer why you personally would model it that way?

It is my understanding of the (informal) property :occurrenceOf that it doesn't assert that statement, just points to it. Isn't that the assumption everybody is working under?


Yes, it is. My question was more on why you want to assert the triple you are talking about even in cases where you know that it is not true t the time you state it.





I gave one reason already in my example: me authoring this in 1967.

I would expect that you remove or change your statement the moment it becomes wrong (like you would for example update wikipedia).  But even if you don’t, your statement comes in some context (maybe a graph) and you could add meta-information to that. I would not put that information as triples in the same graph since that makes your graph difficult to process (it is in some sense similar to a written text with a lot of footnotes, at some point the meta-information hinders readability).



I can easily give more examples:
   <<:Alice :married :Bob>> :in :GretnaGreen .
Some people would accept that as a marriage, others wouldn’t.

That is true. But the moment you state that they are married, you show that in your opinion it is a marriage.

   <<:Alice :plays :Piano>> :with :Hammer .
Some people do that, some people comnsider it art, some people disagree.
  <<:Alice :plays :Guitar>>
alone is according to your approach a highly dubious statement and wrongly modeled because she sure doesn’t play guitar in her sleep.

That highly depends on what „:plays“ actually means. But again: if you state it, it is true according to you (it is my problem whether or not I want to believe you).


Asking it the other way round: which fact is sure enough to last (and maybe also be undisputed) forever that you would model it as a straightforward triple?  There’s always additional detail, no description is complete - how do you suggest dealing with that? If you model everything as an n-ary relation with a blank node as identifier you are safe. But then you’re essentially back at a glorified version of relational databases (with descriptive column names, granted). Now, I don’t think that graphs are the structure to rule them all but the simplicity of triples, annotated or not, certainly has its appeal. Where does your approach leave that?

As said, I see the knowledge we model as some kind of snapshot of what we believe is true. Of course this concept of „true“ is fluent and what has been true yesterday does not necessarily have to be true tomorrow. But I think that it is the responsibility of the data modeler to at least try to only publish data of which he thinks that it is true and maintain it (i.e. remove triples which are no longer true).




But I guess the answer to that is that you would like to be close to property graphs and there, all triples you  refer to, are also asserted. So I got my answer (if I understood correctly).

No, that’s not my point. I want to be able to annotate statements because I see that as an intuitive way to model things, yes.

OK, then I really misunderstood you, sorry. As pointed out, my problem with your proposal is that you are changing the semantics of what already exists.  So, asking back: if we go your way, is it then even possible to have triples without annotation? What does:

:Alice :plays :Guitar .

mean?


Of course, I disagree that this is a good way to model your examples ;) but I think that has already been discussed in depth on this list.

I don’t understand exactly what you refer to. Do you consider the example you gave above, omitting the asserted statements, a good way to model this? That would however leave me wondering if Alice actually played guitar or not.

Or would you go a totally different route, eg this:
   :Alice :plays [ rdf:value :Guitar ; :mood :Happy ] .

And do you think that RDF-star in geeral shouldn’t be used to model in  property graph style?

I think RDF-star should (amongst other things) be used to model property graph style. I simply don’t want to give up all we have so far to achieve that and I also think that that would be the wrong way. If we do everything exactly like it is done in property graphs even ignoring the existing semantics of RDF, I wonder why do we even need RDF. Why don’t we simply use property graphs in the first place? Or, if you want to have more complex models, why not simply natural language?

Kind regards,
Dörthe


Best,
Thomas

Kind regards,
Dörthe

Best,
Thomas

Kind regards,
Dörthe



Am 20.12.2021 um 01:31 schrieb thomas lörtsch <tl@rat.io<mailto:tl@rat.io>>:

tl;dr
RDF semantics is based on sets and RDF-star builds on that. However RDF-star triple annotation has to deal with the practice of RDF, not its theoretical ideal. In RDF as practically employed multisets, although not the norm, can appear almost everywhere. A design that ignores them per default but requires rewriting data and queries when they appear will not fare well in practice. The problem is inherent in the verbosity of the quoted triple identifier: it favors a syntax that is in almost all cases at least risky, if not outright wrong. The shortcut syntax might provide a way out of this dilemma.


The following examples should illustrate that multisets have to be expected almost everywhere in RDF data. From now on I’m always assuming the standard use case where an actual assertion is annotated:

#0    :Bob :bought :Car .
 :RichardB :marriedTo :LizT .
 :Alice :plays :Guitar .


The CG report says that 'Alice said that Bob bought a car' should be modeled not as

#1    <<:Bob :bought :Car>> :said :Alice .

but as

#2    [] :occurrenceOf <<:bob :bought :Car>> ;
    :said :Alice ;

because there might be other sources for the same statement. That’s always possible so it seems reasonable to always require the indirection of creating a proper occurrence identifier when annotating a statement with provenance.


Likewise it was recently discussed that marriages between Richard Burton and Elizabeth Taylor should not be modeled as

#3    <<:RichardB :marriedTo :LizT>> :start 1966 .

but rather as

#4    [] :occurrenceOf <<:RichardB :marriedTo :LizT>> ;
    :start 1966 .

beacuse we know of that second marriage.

But what if we didn’t? What if we had authored this in 1967, assuming that this marriage will last forever? Would we have chosen the more involved modelling style nonetheless? And if we did go with the succinct #3 version - very probably, at least according to current thinking I assume - will we later, after their second marriage, have to change that to #4 style?

What about querying? Say we are not sure if some statement occurs only once or multiple times: will we have to query for both modelling styles? Probably.


While the first example could be categorized as describing a speech act and the second example might be considered instantiation there’s also the case of subclassing. For example we might want to describe that Alice happily plays guitar:

#5    <<:Alice :plays :Guitar>> :mood :Happy .

The other day however she plays guitar because she's sad:

#6    <<:Alice :plays :Guitar>> :mood :Gloomy .

"So which one is it?" the unexpecting data consumer might complain. It turns out that indeed we should have chosen the more involved style right away.
And that is precisely my concern: the succinct modelling style as in #1, #3, #5 and #6 only works if we can be _sure_ that we are dealing with triples as types - not occurrences, not instances, not subtypes, not whatever other (not so) special cases there might exist.

The succinct triple-as-type style only works for use cases that the proposed semantics was optimized for, when working on the very low levels of RDF machinery. In any other case the succinct style can be used first but might need to be changed later, and it requires queries to account for both modelling styles. Both prospects are bad enough to warrant a general rule that says: don’t use the succinct style, use the indirection via creating a statement identifier if you are not really sure that your use case is Explainable AI, versioning or similiarily close to the metal.


In my understanding the problem stems from the very core of RDF-star’s design: RDF-star quoted triples are verbose in that they quote in full what they identify. That leads to moral hazard: it’s all too easy to take the shortest path and use the type as an identifier where one should mint a proper identifier first. The proposed semantics take advantage of that verbosity and put it to good use of it for those special use cases that require a carbon copy of their subject. But it is not well suited for annotations that influene the meaning of the annotated triple. Maybe it helps to think about the problem this way: property graph style modelling allows to keep the simple triple and yet enrich it with additional detail. But one must admit that the simple triple annotated in two different ways is then not the same triple anymore.


I was all along (summer of 2020 IIRC) arguing for proper statement identifiers like RDF/XML provides them and I still think they are the right solution for mainstream use cases as they are much closer to the reality of RDF data and therefore better positioned to capture deviations from the abstract RDF core. Maybe there is a middle ground in the shortcut syntax which could be defined as expanding to identifiers by default - e.g.:

:Alice :plays :Guitar {| :mood :Happy |}
:Alice :plays :Guitar {| :mood :Moody |}

expanding to

:Alice :plays :Guitar .
[] :occurrenceOf <<:Alice :plays :Guitar>> ;
  :mood :Happy.
[] :occurrenceOf <<:Alice :plays :Guitar>> ;
  :mood :Moody .

This is guaranteed to be correct for single _and_ multiple occurrences alike, it is easy to author per the shorthand syntax and it is unambiguous to query.
All more involved use cases - explainable AI, unasserted assertions etc - work as before, as intended, using the quoted triple syntax.
I’d very much favor that default expansion to use a transparency enabling version of :occurrenceOf in which case the shorthand syntax would really be the syntactic sugar for RDF stanard reification that RDF-star was - and, I guess, outside these specialist circles still is - expected to be. That wouldn’t hurt the specialist use cases in any way.


Best,
Thomas


P.S. w.r.t. "a can of worms": Knowledge representation is indeed a can of worms, and always has been, at least since the old greeks. Statement annotation in RDF is a topic well known to be situated right in the heart of the worm hole. There’s not simple genius way around that.