Subject/Object asymetry - Re: Consolidating triple/edges

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.

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.

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

> 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'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...

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

> 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) .

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.

   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


>   (...)