Re: multisets everywhere

Hi Fabio


> << :salvatormundi dc:creator :leonardo >>
>         prov:wasAttributedTo :martinkemp .
>
> << :salvatormundi dc:creator :boltraffio >>
>         prov:wasAttributedTo :jacquesfranck .
>

Very quick aside, I think maybe that should be rewritten as something like
this, but I'm actually not sure:

_:a :statementOf << :salvatormundi dc:creator :leonardo >> ;
        prov:wasAttributedTo :martinkemp .

_:b :statementOf << :salvatormundi dc:creator :boltraffio >> ;
        prov:wasAttributedTo :jacquesfranck .

My whole point is: is there a general way (i.e., not relying on local
> interpretations) to express without asserting a) individual triples and b)
> bunches of triples, and associate them to constraints that determine under
> which conditions they are asserted and under which conditions they are not?
>

This whole conversation is very interesting because it touches so many
different facets of what we're doing. It seems like what you're asking for
here is analogous to *conditional statements* found in programming, for
example if-then-else:

if (Statement1 AND Statement2 AND Statement3)
then (Statement4 AND Statement5 AND Statement6)
else (Statement7 AND Statement8 AND Statement9)

I don't know if something like that exists, but if it doesn't then maybe it
could be something as simple as that?

My obvious reaction would be: there are two kinds of graphs, asserting and
> non-asserting graphs, and we need two separate structures and syntaxes for
> the two of them, and this is what I am humbly trying to propose. You
> mention referential transparency (I am personally starkly in favour of it
> and do not see the big deal with referential opacity, but I am in no
> position or interest in debating it). These are two dimensions to work on,
> which creates four types of graphs:
>
> 1) asserted graphs with referential transparency
> 2) asserted graphs with referential opacity
> 3) non-asserted graphs with referential transparency
> 4) non-asserted graphs with referential opacity
>

I really like this type of approach, looking for consistency and
symmetries. The following might be a bit much, but a couple of years ago I
realized there might be something to learn about modeling from the way
sentences are structured in linguistics, especially in regards to how to
deal with n-ary relationships. I'm no expert, but in linguistics there are
four different types of sentence structures:

   - Simple sentence
   - Complex sentence
   - Compound sentence
   - Compound-complex sentence

In my mind these could map to something like this (I'm leaving out the
extra time and space positions that I've been advocating for to simplify
the demonstration, but they easily slot right in):

*Simple statement:*
:a :name "Alice"

*Complex statement:*
:a :name "Alice"
    :statedBy :bob
    :recorded "2021-07-07"^^xsd:date

*Compound statement:*
{
    :a :name "Alice"
    :b :name "Bob"
    :c :name "Charlie"
}

*Compound-complex statement:*
{
    :a :name "Alice"
    :b :name "Bob"
    :c :name "Charlie"
}
    :statedBy :bob
    :recorded "2021-07-07"^^xsd:date

One might see similarities to simple RDF triples, RDF-star triple
annotation syntax, and RDF graphs in the first three examples, ideally
though any of these statement types could be nested in any of the other
statement types, and the complex statement type *does not* expand/get
broken out to a set of simple statements like the RDF-star annotation
syntax - instead it just is what it is, a complex statement and an
established way of expressing n-ary relationships. Sets of compound
statements are analogous to RDF datasets in my opinion, and you have the
potential for sets of sets and so on.

Asserted vs unasserted, as Fabio asked, would be addressed in the same way
as in RDF-star: only top-level statements are asserted, nested statements
aren't, and that would apply to all the statement types. Referential
opacity would probably be handled in the same way as in RDF-star with a
"statementOf" relation or something to that effect.

Because any statement type can be nested in any other statement type you
then see that everything can be expressed using only complex statements at
the top level.

For logical completeness, but no practical purpose in my view, a complex
statement could actually be extended further. The statement fragments in
the example above, ":statedBy :bob" for example, could be described as
first-order fragments, you could then have second-order fragments,
third-order fragments, and so on up to infinity. Not much practical use
after first-order fragments though in my opinion.

Anyway, that was long, but I'm just trying to say that linguistics seems to
have a system worked out already, one that we're all naturally expert at
using, and maybe we can incorporate things from that system, or at the very
least use it to understand our own system better.

Regards
Anthony


On Wed, Dec 22, 2021 at 8:32 PM Fabio Vitali <fabio.vitali@unibo.it> wrote:

> Hello.
>
> >> On 21/12/2021 17:53, thomas lörtsch wrote:
> >>> (...)
> >>> This is a problem with more than one dimension:
> >>> - between asserted and not asserted there are degrees of "asserted
> under certain conditions", like e.g. the assertion of the marriage between
> Taylor and Burton only being valid in certain periods
> >>>
> >> In RDF semantics (both the current standard and the proposed RDF-star),
> a triple is either true or false. Any "degree of assertedness" or
> "conditional assertion" falls outside the standard base semantics. Of
> course, an application can extend the base semantics (using RDFS/OWL
> axioms, N3 rules, or hard-coded mechanisms) in order to handle intermediate
> forms of assertions. But then, in order to be interoperable with other
> applications, triples that are "conditionnally asserted" from the p.o.v. of
> the app should be *not* asserted from the p.o.v. of the base semantics.
> >
> > Tell that Fabio, not me. If you don’t assert those triples explicitly
> then in plain RDF they are not asserted at all. Consequently what Dörthe
> and Fabio propose may of course work as desired in local applications but
> on the semantic web at large is quite invisible.
>
> No. The whole point of having quoted triples with RDF* or conjectural
> graphs is to generate triples that are expressed but not asserted
> REGARDLESS OF THE LOCAL APPLICATION. This is THE purpose. If we could rely
> on local interpretations of the assertedness of triples then there would be
> no need to discuss about them in a W3C forum.
>
> My whole point is: is there a general way (i.e., not relying on local
> interpretations) to express without asserting a) individual triples and b)
> bunches of triples, and associate them to constraints that determine under
> which conditions they are asserted and under which conditions they are not?
>
> > I know that but it captures only part of reality. Your fellow logician
> Dörthe asked me in this thread the other day why I asserted that <:RichardB
> :marriedTo :ElizabethT> when I already knew that this is not true, or only
> during a certain timespan. Adding the start and end date does change the
> meaning of what is asserted already, triples do indeed interact, and even
> more so when you consider statement annotation or property graph style
> modelling.
> >
> > Or was it sloppy wording on part of the property chosen? But a quick
> check shows that very few properties in use on the semantic web reflect on
> their temporal validity. Past, present, future, time periods, whathaveyou -
> it’s all the same to them. Likewise with spatial, legal or any other
> dimension of validity of the statement in question. If you now insist that
> this is not valid RDF I could rethorically ask back "then, what is, out
> there on the actual semantic web?". Very very little, I assume. And yet it
> works, because assumptions are made _everywhere_. Otherwise everything
> would be just too tedious to be even remotely useful.
>
> The point is NOT whether or not people in the real world actually use
> triples with limited or constrained validity: of course they do use them
> and have been using them for some time. The problem arises when you have
> multiple statements that, taken in an absolute manner, are reciprocally
> inconsistent or even wrong, but can be clarified and made consistent with
> the application of specific constraints.
>
> Take for instance the painting Salvator Mundi (
> https://en.wikipedia.org/wiki/Salvator_Mundi_(Leonardo) ): there are
> multiple authorial attributions to it, the most important of which is to
> Leonardo da Vinci (which caused Christie's to sell it to an Arab prince for
> US$450M in 2017 - the highest price ever paid for a painting). This
> attribution is backed by Martin Kemp (and others). Other scholars (e.g.,
> Jacques Franck) believe it to be a copy from Leonardo by one of his pupils,
> possibly Giovanni Antonio Boltraffio.
>
> So with RDF* you can correctly represent it with non-asserted triples:
>
> << :salvatormundi dc:creator :leonardo >>
>         prov:wasAttributedTo :martinkemp .
>
> << :salvatormundi dc:creator :boltraffio >>
>         prov:wasAttributedTo :jacquesfranck .
>
> The problem solved by RDF* here is NOT simply acknowledging the provenance
> of the statements (which could be done in many different ways), but in
> preventing anyone, with or without inferencing engines, from assuming that
> Leonardo and Boltraffio worked together on the painting or, even, that they
> were the same person.
>
> Multiple coexisting and inconsistent statements over the same entities are
> still VERY HARD to express, and people in the real world either ignore the
> problem, restrain themselves (e.g., by not expressing the less-likely
> triples), or create complicated workaround based on n-ary relations or ad
> hoc classes, etc. CIDOC-CRM has a very complicated workaround based on a
> conceptized n-ary relation exactly for disputed attributions.
>
> If there is ONE thing for which digital humanists anxiously await RDF*, is
> to finally be allowed to express multiple competing hypothesis over the
> same entities without self-restraint, mis-representations or convoluted
> structures.
>
> > We can go back again to n-ary relations and model the marriage like this:
> >
> >    :RichardB :marriedTo [
> >        rdf:value :ElizabethT ;
> >        :start 1966
> >    ]
>
> Indeed. This is a remedial approach, requiring people to "conceptize"
> relations so that triples can be given an identity and an IRI and
> annotated. Far from ideal.
>
> > We can use graphs to separate "same" triples and then annotate them in
> different ways to get multisets. RDF standard reification vocabulary pulls
> identifiers for occurrences (or "speech acts") out of thin air. Nobody gets
> hurt, we just play tricks with the logic. That sort of creativity is what’s
> needed. If named graphs hadn’t been so over-eagerly defined as
> referentially opaque but had been provided as a mere grouping mechanism -
> no more, no less - we would have much less problems today. But it’s easy to
> say in hindsight. Maybe not too late, who knows.
>
> I for once totally agree with you on this: not specifically about the
> referential transparency/opaqueness issue, I am more interested in the
> discussion about the truth value of their content. Still, I agree with you
> that the perfect solution would exists, named graphs, but it is
> underspecified, which makes them just too vague for practical purposes.
>
> My obvious reaction would be: there are two kinds of graphs, asserting and
> non-asserting graphs, and we need two separate structures and syntaxes for
> the two of them, and this is what I am humbly trying to propose. You
> mention referential transparency (I am personally starkly in favour of it
> and do not see the big deal with referential opacity, but I am in no
> position or interest in debating it). These are two dimensions to work on,
> which creates four types of graphs:
>
> 1) asserted graphs with referential transparency
> 2) asserted graphs with referential opacity
> 3) non-asserted graphs with referential transparency
> 4) non-asserted graphs with referential opacity
>
> I am interested in 3) or 4). I assume you are interested in 1) or 3).
> Maybe we can identify 2) and 3) as the most urgently needed varieties of
> graphs and propose a simple split of the current concept?
>
> > OTOH, time and again I’ve sworn myself to not take part in this CG any
> longer as for my taste it is just not interested enough in finding a good
> solution for meta modelling on the semantic web. Tediously did this CG need
> to be motivated to tackle real world issues like occurrences, referentially
> transparent triples and the like. Whatever this CG really is interested in,
> and why, is still not really clear to me, but it seems to be quite
> theoretical. So, the temptation to sit this CG out and wait for a real WG
> with hopefuly some more practically oriented participants has always been
> strong. But I also learned a lot.
>
> If a CG is what is in the menu now, then CG is what we should be eating.
> If the kitchen is preparing starters you cannot complain there is no main
> entrée.
>
> My impression is that very little will be discussed in a real WG that
> hasn't been at least considered in one of the CGs that will feed it. This
> is why it is important that the output of this CG report also the issues
> that weren't approved, but were at least discussed.
>
> My 2c is: please make sure that a smooth transition exists between
> expressed-but-not-asserted triples and expressed-but-not-asserted
> containers of triples, and that their semantics is independent of
> application-dependent choice of the semantics of triples and containers.
> This is ALL I need.
>
> Ciao
>
> Fabio
>
> --
>
> Fabio Vitali                            Tiger got to hunt, bird got to fly,
> Dept. of Computer Science        Man got to sit and wonder "Why, why, why?'
> Univ. of Bologna  ITALY               Tiger got to sleep, bird got to land,
> phone:  +39 051 2094872              Man got to tell himself he understand.
> e-mail: fabio@cs.unibo.it         Kurt Vonnegut (1922-2007), "Cat's
> cradle"
> http://vitali.web.cs.unibo.it/
>
>
>
>
>