proposal: let the shorthand syntax default to referentially transparent occurrence

[rat10]

This is not a fully worked out proposal but influenced by and to be understood in context with the ongoing discussions on referential opacity and an occurrences vocabulary.

What if we defined that the shorthand syntax refers to referentially transparent occurrences, to the effect that:

:alice  :buys  :car  {| :color  :red ;  :on  :monday |}

would in unabbreviated syntax expand to

:alice  :buys  :car. 
_:x  rdfx:occurrenceOf << :alice  :buys  :car >> ;
     rdfx:inGraph  <> ;
     rdfx:semantics  rdfx:tripleTermsTransparent ;
     :color  :red ;
     :on  :monday .

The shorthand syntax would cover what IMO is the predominant use case. The pointy bracket syntax would loose nothing of its expressive power but the nasty side effects would be contained as lazy, ill-educated or just plain unaware users would probably stick to the much easier to use and wider supported shorthand syntax.

The unabbreviated syntax with embedded triples in pairs of pointy brackets stays unchanged as currently defined (until of course it is extended to sets of embedded triples, to finally arrive at its N3-ish destination ;-> ).

And last not least a clear and not too cumbersome path from referentially opaque to transparent semantics would be provided, something the proposed semantics so far is sorely lacking and only vaguely refers to as some TBD 'semantic extension'. IMO this displays a disgraceful neglect to the original use case of RDF-star. The proponents of the proposed semantics are very forthcoming in emphasizing the wide support of RDF-star but they never say that the proposed semantics makes the seminal use case on which that support is founded blow up in triple size to nearly the much maligned RDF standard reification quadlet. The above proposal would at least remedy that pain.

[TallTed]

You're still applying :color where it is nonsensical.

:color is not being used as an attribute of :car, nor of :alice.

_:x :color :red is simply a nonsensical statement, given the other attributes of _:x.

This renders the rest of what you say difficult to understand clearly, never mind take seriously.

[rat10]

You're still applying :color where it is nonsensical.

:color is not being used as an attribute of :car, nor of :alice.

_:x :color :red is simply a nonsensical statement, given the other attributes of _:x.

This renders the rest of what you say difficult to understand clearly, never mind take seriously.

Man, you're on the loose! Already answered here and referenced here. No need to make the same comment three times.

[afs]

I would say this isn't reusing abbreviated syntax because that expands to <<>> form during parsing.

It's another first-class concept. e.g. it's a term <| :s :p :o |> meaning "transparent".

A translation approach does loop back to the issues of using multiple triples like reification.

[TallTed]

No need to make the same comment three times.

Really? You created this issue, when the other two on pretty much exactly the same topic were already being actively discussed.... So there does appear to be such a need.

[rat10]

@afs

I would say this isn't reusing abbreviated syntax because that expands to <<>> form during parsing.

The shorthand

:alice  :buys  :car  {| :on  :monday |}

expands to

:alice  :buys  :car 
<< :alice  :buys  :car >>  :on  :monday .

In my expansion example above the embedded triple is in the object position and 3 more statements are added. I don't see a principal difference between the two. Can you please explain?

It's another first-class concept. e.g. it's a term <| :s :p :o |> meaning "transparent".

I wouldn't necessarily be opposed to another first-class concept but I'm also not convinced that we need to go that far just because of certain implementation considerations.

A translation approach does loop back to the issues of using multiple triples like reification.

The shorthand syntax already requires multiple (at least two) triples to translate to the double pointy brackets syntax so my quite basic programming skills tell me that you already need some datastructure if you want to gather those two triples, and expanding from 2 to 4 is then usually not a problem anymore. Also, what do you do with the proposed occurrence syntax? Do you gather those two statements - rdfx:occurenceOf and rdfx:inGraph - together or do you treat them as individuals. What's so different?

Also, I'm a bit wary of "early optimization". I'm aware that Pavel reported the same pains as you do w.r.t. reification quadlets, but I'm still not overly convinced that there's not a way around this.

[afs]

The experience with reification and multiple triples has a long history. It is not a new concern.

Any proposal needs to reflect the issues that arise (number of triples; multiple joins; definition when incomplete collections of triples are encountered) or it will suffer in the same way.

Can you please explain?

In annotation syntax, the expansion is not linked, just like :s :p :o1, :o2 .

In your proposal, and like reification, the expansion as a group is given meaning.

[rat10]

The experience with reification and multiple triples has a long history. It is not a new concern.

Any proposal needs to reflect the issues that arise (number of triples; multiple joins;

It was certainly not my idea that the explainable AI use case gets all the syntactic sugar while the much more main stream use case of annotating triple occurrences has to be modeled with 2 to 3 extra triples. That triple count would be reduced (at least on the surface) with my proposal.

definition when incomplete collections of triples are encountered)

I'm not overly concerned about that. I assume that any triple that is lost in transmission is a loss with hard to calculate consequences. What is the difference to any other tree-shaped object? I would also assuem that it doesn't happen too often.

What could happen? What is the experience with reification?

or it will suffer in the same way.

Can you please explain?

In annotation syntax, the expansion is not linked, just like :s :p :o1, :o2 .

Which might also be considered a problem, not a feature, as it makes a big difference if an embedded and annotated triple is actually asserted or not. Also it might make a big difference if the annotation to a triple is lost or not. So how is this any less critical?

In your proposal, and like reification, the expansion as a group is given meaning. Let's take the axample from above, line by line:

1    :alice  :buys  :car. 
2    _:x  rdfx:occurrenceOf << :alice  :buys  :car >> ;
3         rdfx:inGraph  <> ;
4         rdfx:semantics  rdfx:tripleTermsTransparent ;
5         :color  :red ;
6         :on  :monday .

Line 1 is the same in both approaches. Line 2 is crucial for the annotations to make any sense. Line 3 and 4 are not essential. Line 5 and 6 are annotations that depend on the crucial line 2. Maybe that looks problematic to you. However, what if we drop the above proposal. Then if I want to annotate a referentially transparent triple occurrence I arrive at exactly the same set of triples. I just can't use the shorthand syntax. What is won by that?

[afs]

What is won by that?

Annotation syntax can be used for the original motivating use case for the syntax,

[rat10]

What is won by that?

Annotation syntax can be used for the original motivating use case for the syntax,

It would be helpful if you provided a little more background to your comments, answered a little more of my questions and in general weren't so extremely terse and difficult to parse.

I can only guess what your comment refers to as "the original motivating use case for the syntax". When the syntax was proposed the proposed semantics weren't an issue, syntactic considerations were. Those are not touched by my proposal. The original use case is the use case that RDF* catered for, now documented in the Community Group Report as the seminal example. That is about referentially transparent occurrences of triples and that is what the above proposal lets the shorthand syntax default to.

[afs]

When the syntax was proposed the proposed semantics weren't an issue, syntactic considerations were. Those are not touched by my proposal.

I can not reconcile that statement with your proposal which is a different expansion and also removes the possibility annotation syntax when rdfx:semantics rdfx:tripleTermsTransparent ; is not intended.

What if we defined that the shorthand syntax refers to referentially transparent occurrences, to the effect that:

:alice :buys :car {| :color :red ; :on :monday |} would in unabbreviated syntax expand to

:alice  :buys  :car. 
_:x  rdfx:occurrenceOf << :alice  :buys  :car >> ;
     rdfx:inGraph  <> ;
     rdfx:semantics  rdfx:tripleTermsTransparent ;
     :color  :red ;
     :on  :monday .

If you change the expansion, it is not the same syntactic sugar.

[pchampin]

This was discussed during our last call: https://w3c.github.io/rdf-star/Minutes/2021-05-28.html#x214

[rat10]

@afs

When the syntax was proposed the proposed semantics weren't an issue, syntactic considerations were. Those are not touched by my proposal.

I can not reconcile that statement with your proposal which is a different expansion and also removes the possibility annotation syntax when rdfx:semantics rdfx:tripleTermsTransparent ; is not intended.

What if we defined that the shorthand syntax refers to referentially transparent occurrences, to the effect that: :alice :buys :car {| :color :red ; :on :monday |} would in unabbreviated syntax expand to

:alice  :buys  :car. 
_:x  rdfx:occurrenceOf << :alice  :buys  :car >> ;
     rdfx:inGraph  <> ;
     rdfx:semantics  rdfx:tripleTermsTransparent ;
     :color  :red ;
     :on  :monday .

If you change the expansion, it is not the same syntactic sugar.

I'm really not sure I get your point. To clarify I see the following differences (listed verbosely to help understanding):

• my proposal expands to a referentially transparent occurrence, not an opaque triple
• it expands not to 2 but 4 statements
• there is no abbreviated syntax for the referentially opaque use case but it can still be modelled embedded triples.

Is that all or did I miss something essential?

You didn't comment on what you think the original use case is nor on my guesstimate that from a programming perspective it makes little difference if a data structure has 2 or 4 entries nor on the following argument above:

In annotation syntax, the expansion is not linked, just like :s :p :o1, :o2 .

Which might also be considered a problem, not a feature, as it makes a big difference if an embedded and annotated triple is actually asserted or not. Also it might make a big difference if the annotation to a triple is lost or not. So how is this any less critical?