Re: Proposal for RDF-star Minimal Baseline - Agenda item for this week's plenary

Hi Enrico,

One addition:

If we really want to go for the well-formed syntax, we could make a stronger restriction and only allow rdf:reifies in predicate position and only together with a triple term as object. But in that case, I would change the semantics even more and treat  rdf:reifies differently than a normal predicate (we would, for example, not have to derive rdf:reifies a rdfs:Property). But all this goes, in my opinion, too far. I just put it here as a mental experiment.

Kind regards,
Dörthe

Am 18.07.2024 um 19:26 schrieb Doerthe Arndt <doerthe.arndt@tu-dresden.de>:

Dear Enrico,

Am 18.07.2024 um 17:57 schrieb Franconi Enrico <franconi@inf.unibz.it<mailto:franconi@inf.unibz.it>>:

Hi Dörthe,
I’m happy you bring us your comments.

- injectivity of RE: in my opinion there is no real reason to make the function injective and I think it could cause harm in the sense that such restriction can lead to inconsistencies when we extend the logic.  I guess that was discussed in a task force meeting I was not present? Maybe I can read it up somewhere?

It is true that injectivity could cause harm in extensions. That’s why we created the well-formed fragment, and we expect that extensions should only consider the well formed fragment (where there are no isolated triple terms). In fact, injectivity of the denotation of a triple term is harmless if we restrict ourselves to the well formed fragment.

That is a funny way of talking me into the well-formed fragment: You introduce a problem I don’t think we have and then create a solution.  ;)
I agree that the well-formed semantics solves that, I just doubt that we need to create the problem.

We can not drop injectivity, since the semantics of a triple term would be wrong.

Strong statement given that we have that many use cases and opinions. ;)

The resource denoted by a triple term should be unique, since it represents the (unique) semantics of the triple in the interpretation - it is the “type". It would be not faithful to have a triple term denoting different resources in an interpretation: what would the additional resources represent?

I am very confused by this. I think we are mixing up syntax and semantics. If your triple term only stands for one resource, why should we have transparency?  If a:loves and b:loves are denoting the same relation, then << :x a:loves :y>>  and << :x b:loves :y>> refer to the same resource, but if I have a triple term << :y a:isLoved :x>> it has to be different? Where are we drawing the line and why? That is not clear to me. Or are we only going for transparency to make simple entailment easier? I could live with that as well, I just want to know. :)

That’s what model theory is about, namely to reconstruct interpretations (“models”) which faithfully represent the intended world; here, in the world there is a unique meaning for a triple term.

You can easily think of use cases where people want something different. Like

:s :p << :x :loves :y>>.
:s :p << :y :isLoved :x>>.

I can imagine, that some people would want to have the same meaning for << :x :loves :y>> and << :y :isLoved :x>> if they expect this to be the same statement (really depending on how you see your triple terms, you exemplified many view points).

You could now say that we can get away from this using the same reifier (= subject of rdf:reifies) for that equality, but if we argue like that, the same argument goes for getting transparency.


Do we need the injectivity for the mapping to and from LPGs? Or where do we have the need?



- semantics of triple terms: in your abstract syntax, the :a :b :c in your triple :s :p << :a :b :c>> is a triple and a triple term at the same time, in my opinion, it is therefore not clear that the [I+A](t.o) in the interpretation  [I+A](t) of the overall triple refers to the term interpretation and not the triple interpretation. I think that should be stated more clearly. We should emphasize the difference between a triple and a triple term.

You are right. I have to fix the syntactic categories used in the grammar.

- well-formed semantics: I don’t think that it really works make the restriction on rdf:reifies as you currently do it in the well-formed syntax. As I have RDFS, I could declare:

doerthe:reifies rdfs:subPropertyOf  rdf:reifies.
rdf:reifies rdfs:subPropertyOf  doerthe:reifies.

Now, I have a predicate doerthe:reifies which behaves like rdf:reifies and this makes the restriction not really strong (thinking about it, it is interesting, that I(rdf:reifies) and I(doerthe:reifies) can still differ). I think we could drop the restriction, but I also did  not fully understand the reason for having it in the first place, maybe you can explain?

For the same reason that in RDFS we give a special meaning to rdf:type in defining the extension of classes: only rdf:type gives meaning to the extension of classes and this is explicit in the meta model. Similarly to your case, I could create a fake pseudo-equivalent predicate doerthe:type, but this would not be explained by the meta model and would not have a role in defining a class.

The case is different. We do not have syntactic restrictions on rdf:type (do we?). Of course we can mimic the predicate. My point was more: why do we make a syntactic restriction if that has no impact? Or is the impact, that we simply cannot entail new triples with rdf:reifies in predicate position? Why do we do that? A technical reason which would make it easier to get  back to the syntactic sugar?




We can still keep that triple terms may only be in the object position of rdf:reifies, even though, I dislike that (I think I already explained why, mainly because I want to be able to express all logical consequences, but that is a separate topic).

I don’t follow here.

OK, that was maybe too short, sorry. I wanted to say that I do not see the added value of allowing the rdf:reifies predicate only in predicate position when followed by a triple term. I initially thought (when I wrote the last e-mail), that I would still be fine with only allowing triple terms to occur after rdf:reifies. I am not sure about that, the more I think about that.

So basically, I discussed the two points separately:

1. Triple terms are only allowed as object of rdf:reifies.
2. rdf:reifies is only allowed in predicate position when followed by a triple term.

I initially argued that we should have 1 but not 2, but thinking it through, I actually dislike both and mainly for the same reason: It is a syntactic restriction which makes it impossible to properly express the logical consequences of our (valid) reasoning. For example:

doerthe:reifies rdfs:subPropertyOf  rdf:reifies.
rdf:reifies rdfs:subPropertyOf  doerthe:reifies.

:x rdf:reifies <<:s :p :o>>.
:y doerthe:reifies :z.

These 4 triples would normally entail:

:x doerthe:reifies <<:s :p :o>>.
:y rdf:reifies :z.

But both triples are not allowed according to our syntax, we could do

:x doerthe:reifies _:blank.

But not even

:y rdf:reifies _:blank2.

is allowed. And I dislike that, because I would have hoped to get that out by simple entailment.


Kind regards,
Dörthe


- we should start to think about all the RDF meta modeling stuff, because I am curious whether that could lead to problems especially in combination with the well-formed semantics

I violently agree.

cheers
—e.

Kind regards,
Dörthe

Am 16.07.2024 um 19:20 schrieb Adrian Gschwend <adrian.gschwend@zazuko.com>:

Dear group,

During the recent Semantics Task Force call, there was an informal agreement to propose a resolution for the main group [1]. The proposed resolution is to implement the minimal baseline for RDF-star as outlined in the following document: RDF-star "minimal baseline" [2].

The chairs (Ora and I) have discussed this matter and we support bringing this topic to the main group for a formal resolution.

We would like to add this proposal to the agenda for this week's meeting. Additionally, we request that a representative from the Semantics TF present this proposal to the group. Ideally, this could be done via email prior to the meeting to ensure everyone has the opportunity to review and prepare for the discussion.

regards

Ora & Adrian

[1]: https://www.w3.org/2024/07/12-rdf-star-minutes.html

[2]: https://github.com/w3c/rdf-star-wg/wiki/RDF-star-%22minimal-baseline%22


--
Adrian Gschwend
CEO Zazuko GmbH, Biel, Switzerland

Phone +41 32 510 60 31
Email adrian.gschwend@zazuko.com