Re: multisets everywhere

Sorry, I should have picked referentially transparent examples, sorry if
that confuses anybody, I just took the fragments from the CG report and was
focusing on the structures of the statements not the contents of them.
Anthony

On Thu, Dec 23, 2021 at 12:14 AM Anthony Moretti <anthony.moretti@gmail.com>
wrote:

> 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/
>>
>>
>>
>>
>>