Re: AW: Triple-terms only as object of rdf:nameOf triples?

Dear Felix,

On 21/01/2024 12:12, Sasaki, Felix wrote:
>
> What are the implications of this thread and the proposal at
>
> https://github.com/w3c/rdf-star-wg/blob/main/docs/sugar-proposal.md

>
> That proposal says:
>
> “The proposal is to add a new syntactic construct to Turtle and also 
> other complex syntaxes for RDF (not including N-Triples, for example) 
> for named occurrences of triples.”
>
This thread is indeed departing from the "sugar" proposal. In a nutshell:
* both the sugar proposal and this thread assume that concrete syntaxes 
are extended with the "edge" construct (<< :e | :s :p :o >>)
* the sugar proposal does not extend the abstract syntax compared to RDF 
1.1, but maps the edge construct to a bunch of triple, using (for the 
moment) the reification vocabulary
* this thread explores two possible ways to extend the abstract syntax, 
to ensure that whatever the edge constructs maps to is atomic (i.e. 
either entirely in the graph, or not in the graph at all)

In the sugar proposal, an example where atomicity is violated would be:

   :e rdf:subject :s .
   :e rdf:predicate :p.
   # no rdf:object provided for :e

I hope this clarifies things.

> So if I am a producer of n-triples, I would first need to convert them 
> to  turtle to be able to use the proposal?
>
No, neither proposal have this constraint -- god forbid! :)
>
> Best,
>
>
> Felix
>
> *Von: *Andy Seaborne <andy@apache.org>
> *Datum: *Samstag, 20. Januar 2024 um 21:52
> *An: *public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>
> *Betreff: *Re: Triple-terms only as object of rdf:nameOf triples?
>
>
>  
>
> Sie erhalten nicht oft eine E-Mail von andy@apache.org. Erfahren Sie, 
> warum dies wichtig ist <https://aka.ms/LearnAboutSenderIdentification>
>
>  
>
> On 19/01/2024 12:42, Souripriya Das wrote:
>
>     Following up on the discussions in yesterday's meeting, I was
>     thinking that we could actually keep RDF1.2 as a "set of triples",
>     instead of going for "set of triples and set of edges", while
>     keeping things simple by imposing some restrictions on
>     triple-terms and their use (in N-Triple) as explained below.
>
>     Equivalence:
>
>     ===========
>
>     As I noted in yesterday's meeting, the following two are just
>     different ways of expressing the same thing:
>
>      :e | :s :p :o .     # A) uses a special 4th component --> "name"
>
>      :e rdf:nameOf << :s :p :o >> .   # B) has three components at
>     top-level, but uses a complex term, called "triple-term", as the
>     object
>
> Yes.
>
>
>     Restrictions for Simplicity:
>
>     =====================
>
>     We could go with option B (in N-Triple), but keep things simple by
>     imposing the following restrictions on triple-terms and their use:
>
>       * No Nesting: None of the components of a triple-term can be a
>         triple-term.
>
>       * Only as Object: A triple-term can only appear in the object
>         position.
>
>       * Only in rdf:nameOf Triples: A triple-term can be used in only
>         those triples that have the special property rdf:nameOf as
>         predicate.
>
> Mandating such restrictions (RFC 2119 "MUST NOT") is more complicated 
> in the spec, not less. And for users, if material has to explain 
> enforceable restrictions.
>
> We can recommend good usage (even RFC 2119 "SHOULD NOT") , and we have 
> talked about material in the primer.
>
>
>     Note that these restrictions do not constrain expressive power in
>     any way because we can always get a name (e.g., :e) for a
>     triple-term from an rdf:nameOf  triple and we can use that name as
>     as an ordinary term (restricted to use as subject or object).
>
>     Thanks,
>
>     Souri.
>