Some notes on the RDF‐star examples of profiles

Thanks Thomas for the useful comments.

> But first, a general question: is it considered possible to have
> << :e1 | ' :s :p :o ' >>
> refer to a referentially opaque triple and
> << :e1 | :s :p :o >>
> (using the same reifier) to refer to a referentially transparent triple or would they need to have different reifiers?

This is a very important question that requires a well thought answer.
I personally would say yes. But I need more time to write down a proper justification for it. Maybe others may have opinions on this.
Note that the current definitions allow for this.

> Example 1
> =========
> I see no indication why the triple terms in this example have to be opaque - at least no other than the opposition to many-to-many reifications.

The motivation comes from LPG encoding, not from the fraud example.
In LPG an edge identifier is associated exactly and uniquely to a subject,object pair of node identifiers. These identifiers are "static" and uniquely created at assertion time, and they do not denote anything, not frauds, not transactions, not accounts. Just strings, no semantics. They don't change over time.
In order to capture this, we need functionality and opacity.

But please, challenge us on this: we need to sustain any potential future critique!

> If referentially opaque triple terms would become the standard way to represent LPG data in RDF (or if the recommendation would even suggest such an approach) we would probably shoot ourselves in the foot big time.

I agree: I would oppose to have rdf-star with only opaque triple terms.

> A conversion of LPG to RDF that looses some or even much of the integration capabilities of RDF is not a compelling value proposition.

Remember that if rdf-star will have also transparent triple terms, modellers may decide, while converting their lpg into rdf, to semantically enrich their original lpg model, by adding semantics and denotation in the conversion process, and therefore using transparent triple terms. In this way, the rdf graph will be a starting point for a much richer domain representation wrt the original lpg. This is also a big selling point for rdf-star!

> Example 4
> =========
> I don’t see how the entailment could be problematic. Indeed both :mary and :paul stored a statement to the effect that (i.e. meaning that) :liz :married :richard. What’s not to like?

They store syntactic objects (namely specific triples), not their meaning.

> How is that a feature except in cases where one bothers about the syntactic representation of referers?

But that is exactly the point.

> We have a large collection of use cases, scrupulously examined precisely to find out if they profit from or even need referential opacity, and the result was: in the overwhelming majority they don’t need or profit from referential opacity, they’d rather suffer from it. We should stick to that result.

Correct. But we have identified at least two important use cases calling for opacity: lpg and annotation of syntactic objects.

> Example 6
> =========
> How would one argue that adding
> << _:w3 | :BCHRmarriage :in :Fayetteville >> :starts 1975 .
> is not legal? According to example 5 one can’t, and I agree with that. In that sense example 6 is slightly misleading / may lead to wrong assumptions.

I don't get it.
<< _:w3 | :BCHRmarriage :in :Fayetteville >> :starts 1975 .
would be consistent (and legal) with examples 5 and 6.
What is your point here?
Maybe we should better explain and/or work out the examples, so that we all agree on the meaning they should convey.

> Example 7
> =========
> This is in fact a compelling example of how referential opacity can be useful. However, as argued before elsewhere, why not avoid all the baggage and problems  with referentially opaque reifications and go with RDF literals. E.g.:
> 
> << lvn:t1 | :liz :married :richard >> a :TripleToken .
> lvn:t1 :added-in lvn:rdf-registry ; :stored-by :john .
> lvn:t1 :on-date "2006-03-12Z"^^xsd:date .
> lvn:t1 :provenance lvn:database-1975-123973q2 .
> lvn:t1 :originalSyntacticRepresentation ":liz :married :richard"^^rdf:ttl

I believe that this statement is not capturing what you mean:
<< lvn:t1 | :liz :married :richard >> a :TripleToken .
Being transparent the triple term is subject to interpretation and is suffering the issues of example 3.

> I noted that some guys from Amazon (Olaf, Gregory, Ora, Bryan, and others) just published a paper at ESWC where they propose the use of datatyped literals to encode - and query, and update! - lists and maps in RDF [0]. I’m not yet sure if those literals are meant to be interpreted as referentially opaque but I imagine that would be easy to add/clarify.

Yes, they have to introduce this proposal to us.

> Example 8
> =========
> There’s some confusing co-denotation (and/or lack thereof) wrt token identifiers which I gues needs a second look, but I didn’t want to mess with the page (i.e. am afraid of interacting with Git).

Please do.

> Example 9
> =========
> A) I don’t get how the title of the example corresponds to its content. Doesn’t it rather want to illustrate the opposite?

Nope.

> B) Charlie’s inference in the last paragraph is unfounded because the relation stated in c. is incorrect. <alice.ttl> speaks about two annotations, <bob.ttl> about only one. So they hardly can be considered sameAs. Any further entailments based on such a sameAs statement is likely to produce erroneous results, in this case mixing attributes from two different annotations.

I guess you didn't get the gist of the example.
It says that using functional opaque annotations to describe reifications leads to horrible consequences, and I am sure you will agree!

Cheers
--e.

Received on Wednesday, 5 June 2024 14:42:38 UTC