Re: Well-formedness for option 3

BTW, I just made some minor fix, so please reload…
—e.

On 28 Feb 2024, at 10:09, Franconi Enrico <franconi@inf.unibz.it> wrote:

As mentioned several times, you can find the current proposed formalisation of option 3 here:
https://github.com/w3c/rdf-star-wg/wiki/RDF‐star-semantics%3A-option-3<https://github.com/w3c/rdf-star-wg/wiki/RDF%E2%80%90star-semantics%3A-option-3>
cheers
—e.

On 28 Feb 2024, at 10:03, Olaf Hartig <olaf.hartig@liu.se> wrote:

Dear all,

Do we have an email or a document with a definition of well-formedness
in the context of option 3? I couldn't find any, but perhaps I
overlooked something.

The words “well-formed” and “well-formedness” were mentioned in recent
calls that took place after the call in which we came to the consensus
to focus on option 3. So, I assume that group members have an
understanding what the notion of well-formedness for option 3 means.
Yet, I couldn’t find any form of definition for it. The only definition
that I found is the one of a “reification well-formed RDF graph” by
Peter [1], but that one is focused on options 1 and 2, and not directly
applicable to option 3.

So, what is your understanding of a well-formed RDF graph in the
context of option 3?

Mine is as follows: An RDF graph is well formed iff it has all of the
following properties.

- Property 0: None of the triples in the graph has a triple term [2] as
its subject.
(In my reading of option 3, triple terms in the subject are already
ruled out by the abstract syntax itself, which makes mentioning this
property here obsolete. Yet, I still mention it for the moment because
some group members seem to argue for an abstract syntax in which triple
terms may be used in the subject position.)

- Property 1: For every triple in the graph that has a triple term as
its object, the predicate of this triple must be rdf:nameOf.
(I understand that the name of this predicate IRI is still under
discussion.)

- Property 2: For every pair of triples in the graph, if both triples
have a triple term as their object (and, thus, have rdf:nameOf as their
predicate, as per the previous point above) and these two triple terms
are different from one another, then the two triples must not have the
same subject.

I assume that Property 2 might be controversial. It has the
disadvantage that merging two well-formed graphs may result in a graph
that is not well formed according to the notion of well-formedness with
Property 2 included. However, well-formedness without Property 2 makes
implementations that focus on efficient support for well-formed graphs
significantly harder; I mean, without Property 2, such implementations
cannot employ data structures (e.g., indexes) that assume that the
subjects of rdf:nameOf triples functionally determine the triple terms.
Notice also that Property 2 is essentially the option-3 variant of
Peter’s aforementioned notion of a “reification well-formed RDF graph”
for options 1 and 2.

An idea to eliminate the aforementioned disadvantage of including
Property 2 is to allow only blank nodes in the subject of rdf:nameOf
triples, but that’s probably not very desirable either because it would
mean that “occurrences” cannot be named by an IRI. Still, I thought I
should mention this idea as a possible option to address the
undesirable effect on graph merging that Property 2 would imply.

Best,
Olaf

[1]
https://github.com/w3c/rdf-star-wg/blob/main/docs/sugar-proposal.md#criticisms-and-responses


[2]
https://pr-preview.s3.amazonaws.com/w3c/rdf-concepts/pull/78.html#dfn-triple-term