Re: Subject/Object asymetry - Re: Consolidating triple/edges

Hi Pierre-Antoine,

On Wed, Dec 20, 2023 at 8:49 AM Pierre-Antoine Champin
<pierre-antoine@w3.org> wrote:
>
> TL/DR: I'm against restricting triple terms to the object position (at least in the "full" profile)
>
> More below.
>
>> On 19/12/2023 15:58, Niklas Lindström wrote:
>>
>>> On Tue, Dec 19, 2023 at 1:06 PM Andy Seaborne <andy@apache.org> wrote:
>>>
>>> (...)
>>>
>>> I'd expect an entailment such as:
>>
>>     <<( :s :p :o )>> rdf:type .... .
>>
>> Yes, I agree (likely rdf:Triple). Just like this:
>>
>>     <a> rdfs:label "a" .
>>
>> entails:
>>
>>     <a> rdfs:label _:a .
>>     _:a rdf:type xsd:string .
>>     _:a rdf:type rdfs:Literal .
>>
>> right? But not:
>>
>>     "a" rdf:type xsd:string .
>>     "a" rdf:type rdfs:Literal .
>>
>> unless we're using generalized RDF?
>
> (In the following, I will call your 3 graphs above G1, G2 and G3 -- G3 being a generalized graph)
>
> Maybe I will be stating the obvious, but the way you phrase it makes me believe some clarifications are needed.

These are good clarifications. It seems that with "entails" here, I
meant both that it follows and can be expressed in RDF.


> Generalized RDF is an extension of RDF syntaxes (abstract and concrete). It is not an extension of the semantics -- it shares the same semantics as standard RDF.
>
> Any RDF-interpretation [1] verifies that <I("a"), I(xsd:string)> is in IEXT(I(rdf:type)) -- likewise with rdfs:Literal. So in a sense, the facts encoded in G3 are a consequence of any RDF-interpretation. Therefore, any RDF-interpretation that satisfies G1 also satisfies G3, which is how entailment is defined [2].
>
> If we are not using generalized RDF, however, then G3 is not a (valid) graph, and so it can not be entailed by G1. But the facts that it describes, even though they can not be expressed in strict RDF, are still a consequence of G1.

That they are consequences but cannot be expressed is certainly interesting.

I can see that it is a logical encumbrance, and can be considered a
problematic, even fundamental, flaw in current RDF. (I still *kind of*
appreciate it though; see below.)


> (again, sorry if I am stating the obvious, but I wanted to be sure we were all on the same page)

Of course; no worries, we must ensure we're not arguing past each other.


>> I wonder if it is inconsequential to allow triple types as subjects in
>> RDF 1.2 Full but not literals?
>
> If you ask me, it was inconsequential of RDF 1.0 to not allow literals in the subject position, for the reason exposed above... :->

I see how that follows from your reasoning.


>> I'm not suggesting we allow the latter,
>
> More seriously: neither am I. We have enough on our plate, let's not stir that particular hornet's nest...

I agree (although I would like to know more about the various sides of
this controversy).

> However I am opposed to perpetuate this inconsequential asymmetry with quoted triples.

I see your perspective.

Mine is that if we're adding a new kind of self-denoting (some say
"literal-like") RDF term, which does not follow this existing
asymmetry for literals (which I'd call "non-identifiers" or
"self-identifiers") in the subject position, we seem to be adding a
design inconsistency instead, on the premise that triples in RDF 1.1
have a flawed design.

If nobody else has any problems with this, I'd have a hard time
arguing further, and should reasonably settle for "protecting
non-expert users of RDF" with syntax, such as what Andy's proposing
(which is similar to what you've proposed for the annotation form
[1]).

(It still means adding a new complex term which is recursively defined
in two places, as I wrote about in [2]. This is not a minor addition
to RDF. Of course, if we provably need all of that, then so be it.
Also, if RDF graphs can be related to them (as sets of such), and, now
or further down the line, that can be used to model semantics for what
are currently "just" named graphs, RDF would become all the better for
it. I see that as possible even with the asymmetry. Admittedly,
depending on how it is done, that might not be identical to the
current design of graph terms in Notation 3 though (since when used as
subjects they'd have to be occurrences).)


>> but it would kind of make sense if we do the former. For me, that
>> would have to come with some *major* (uppercase) warnings and safety
>> mechanisms (at least in syntax; perhaps also not expected to be
>> storable in graph stores), but there is logic to it.
>>
>> Again, to be clear: I am (of course) not opposed to facts about
>> universals; I've just been saying that it's the occurrences/uses of
>> them that we (commonly) need to talk about (in most use cases,
>> especially the ones using annotations).
>
> This is where I really disagree with you. A triple (s p o) is just as much a fact about s than it is a fact about o. Add owl:inverseOf in the mix, and this becomes obvious. And anyway, forbidding literals in the subject position does not prevents us from talking about universals: e.g. https://dbpedia.org/page/42_(number) .

Yes, I know that [3] [4] (that's what I meant by "there is logic to
it"). Certainly, describing occurrences of universals is one way of
making facts about universals. Here I failed to be clear, since with
"them" I specifically meant "that which triple terms identify"
(themselves as types), not any kind of (IRI- or bnode-identified)
universals whose interpretation we increasingly restrict by stating
more facts about them (such as when defining ontologies or concept
schemes, or for that matter, any individual, atemporal *identity*).

> I don't meant to minimize the importance of UX and ergonomy. That's why I'm supporting Andy's proposal, which adds enough syntactic sugar in Turtle to encourage "good/useful" patterns. But I would keep the abstract syntax as general as possible.

I also support (the principle and design goal of) Andy's proposal.

I see your arguments, and I do think a crucial thing is to get the
ergonomics right, to cater for use cases (mostly "talking about
occurrences", but in so doing, and in general, I concede, "linking" to
the triples themselves), and to avoid the mistakes we've already seen
are otherwise easily made. I still think that allowing triple terms as
subjects might add more complexity than is required for that alone;
but I also see how it is an asymmetry.

The reason that I "appreciate" the asymmetry for literals is that I
kind of see RDF literals as a shortcut ("ends" of the graph, if you
will). "Logically", I think:

    "42"^^xsd:integer

"should" be, *in principle* (not actually):

    <unique-iri-for-xsd-integer-42> a xsd:integer ;
        rdfx:lexical <unique-iri-for-xsd-string-42> .

    <unique-iri-for-xsd-string-42> a xsd:string ;
        rdfx:lexical ( <unique-iri-for-unicode-glyph-4>
<unique-iri-for-unicode-glyph-2> ) .

    # And so on (this will become cyclic).

(It is possibly also owl:sameAs
<https://km.aifb.kit.edu/projects/numbers/web/n42>, if the value space
of xsd:integer is identical to that of the platonic numbers.)

But of course I've never argued for that, since it is an obvious,
pragmatic "optimization" that is a part of the core of RDF (albeit not
defined as this "shortcut", and I might be the only one who thinks
this way).

I do see your perspective and will take all of this into consideration
of course, since triples are another matter than literals. (And when
being in sets, they are graphs.)

Best regards,
Niklas

[1]: <https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Oct/0015.html>
[2]: <https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Dec/0010.html>
[3]: <https://docs.google.com/presentation/d/e/2PACX-1vT6luSkUUGrOgpl8vn_MZesCcE5c6TY2bNbLRGk_upB-yzTmM8BrnbYl8BMvqO2Qm2ZBNFcjwB9yuDZ/pub?start=false&loop=false&delayms=3000&slide=id.g2935bf53f59_0_30>
[4]: <https://www.w3.org/2023/11/16-rdf-star-minutes.html>

>   pa
>
> [1] https://www.w3.org/TR/rdf11-semantics/#rdf_d_interpretations
> [2] https://www.w3.org/TR/rdf11-semantics/#rdf-entailment
> [3] https://www.w3.org/mid/ee3ab0cb-ca6c-4fe6-8283-a92edfc72376@apache.org
>
>  (...)
>
>

Received on Wednesday, 20 December 2023 22:29:20 UTC