multiple kinds of transparency; simplicity over complexity

I thought (or Pierre-Antoine made me to believe as he got me into this ;-)
that given the CG work,
the WG "only" has to update a bunch of specs treating the CG work as a
"delta".

But then I looked deeper, and people posted stuff:

- The CG draft mostly talks of Opacity
https://w3c.github.io/rdf-star/cg-spec/editors_draft.html#ref-opacity ,
  including opacity of literals (i.e. they are considered in their lexical
not value space)

https://w3c.github.io/rdf-star/cg-spec/editors_draft.html#ref-opacity-owl-entailment
  and opacity under reasoning

https://w3c.github.io/rdf-star/cg-spec/editors_draft.html#ref-opacity-d-entailment
- but includes a section on Selective Transparency
https://w3c.github.io/rdf-star/cg-spec/editors_draft.html#selective-ref-transparency
  with rdf-star:TransparencyEnablingProperty (TEP)
- Over a year ago I posted a "reasoning" use case
https://github.com/w3c/rdf-star/issues/200 that I now see is very naive.
  - Pierre-Antoine countered with examples that <<X :connectedTo Y>> cannot
be transparent wrt SymmetricProperty reasoning,
    because consider " <<X :connectedTo Y>> :elevationGainInM 15 "
  - Last night I thought of the Hinterstoisser traverse (see
https://en.wikipedia.org/wiki/1936_Eiger_climbing_disaster):
    4 people were able to cross this difficult place from right to left,
    and the belief they would not need (or would be able to) cross in the
opposite direction cost them their lives.
    So if X and Y are the two ends of this traverse, then "X :connectedTo
Y" was not symmetric in 1936,
    and all the way until a permanent rope was fixed on that traverse
  - But please understand my concern: given an inference regime, new
triples are inferred.
    If SOME rdf-star annotations are not carried over to those triples,
doesn't then rdf-star go against reasoning?
- Enrico Franconi proposed a distinction between "semantic" and
"modal/epidemic" predications;
  which if I understand correctly correspond to referentially transparent
vs referentually opaque annotated triples
- PFPS wrote a case about Propositional Attitudes with
  "should admit substitutions of equal literals, because any person
considers two equal literals to be the same".
- Thomas Lörtsch criticized both "TEP" and "predications" as brittle, TEP
as impractical, and perhaps as putting a "fix" in the wrong place.

On the question of "equal vs equivalent", which is closely related to
transparency:
- About literal "lexical vs value" space:
  - In the PFPS case above he says 42 should mean the same as 042
  - But if you store a triple with integer literal 042 and try to fetch it
looking for a triple pattern with integer 42, you won't find it
  - 042 may mean different things to a mathematician vs a C programmer (who
would read it as an octal number).
    I hate to speculate what it may mean to a **mathematician C programmer**
- About URL equality up to encoding/escaping:
  - I pointed out that both of these are false
    (<https://dbpedia.org/resource/Linköping> = <
https://dbpedia.org/resource/Link%C3%B6ping> as ?foo)
    (sameTerm(<https://dbpedia.org/resource/Linköping>, <
https://dbpedia.org/resource/Link%C3%B6ping>) as ?bar)
  - Andy countered with "That's an encoding problem" and Olaf with "But
this has nothing to do with RDF-star per se"

How about prefixes and CURIEs?
I want to declare that the statements below are false for eternity, for any
"A, B, pred",
because using such ugly prefixes is a sloppiness I would never allow myself:

  <<:A ns0:pred :B>> :said :Vladimir
  <<:A j.0:pred :B>> :said :Vladimir

I know that prefixes are expanded, and
https://w3c.github.io/rdf-star/cg-spec/2021-12-17.html#expand-syntax-forms
talks of similar things.
But why can't I have a semantics that allows me to discuss rdf-star
prefixes?

How about syntactically invalid triples? Why can't I record something like
this
(that malformed URL is almost a real example from some company datasets):

  << <htpz:\\example,com/my new great site> a schema:WebSite >> :judgement
"Syntactically invalid".

I can capture the invalid URL using datatype xsd:AnyURI:

  << "htpz:\\example,com/my new great site"^^xsd:AnyURI a schema:WebSite >>
:judgement "Syntactically invalid".

But it's still nogood because literals cannot be in subject position: why
not?

---

All of the above makes me think that there isn't one kind of transparency
but MULTIPLE.
Maybe we need to think of some "layers of transparency".
This strongly smells of Modal Logic (possible worlds)...
Sorry to say, I don't have any good idea how to describe these layers or
allocate rdf-star triples to them.

Andy and Olaf are right that URL equality up to encoding/escaping "has
nothing to do with RDF-star per se".
But because rdf-star allows us to talk about "talking about triples", it
made us think about some of these issues.
(Looking back at some of the issues, I wonder how we've used normal RDF for
so many years with any measure of success :-)

But we shouldn't forget the original purpose of rdf-star:
to make it as easy to attach data to triples as it is in LPG.
I agree with Thomas that the "90% use" (or what they call the "main path"
in use case diagrams) of rdf-star is to record extra data about triples,
not to deal with exceptional/controversial/sensational/prove-it-in-court
kind of triples.
So I think we should look for ways to simplify our treatment, not to
complicate it.

Cheers!

-- 
Vladimir Alexiev, PhD, PMP
Chief Data Architect
Sirma AI, trading as Ontotext: https://www.ontotext.com, LinkedIn
<https://www.linkedin.com/company-beta/208070>, Twitter
<https://twitter.com/ontotext>,
Email: vladimir.alexiev@ontotext.com,
Mobile: +359 888 568 132, SMS: 359888568132@sms.mtel.net
Calendar:
https://www.google.com/calendar/embed?src=vladimir.alexiev@ontotext.com
Publications and CV: https://github.com/VladimirAlexiev/my