Re: Well-formedness for option 3

Thanks for the pointer Enrico! I was assuming that this document
defines only the semantics but I see now that you define a notion
of reification well-formed graphs at the end of this document.

I notice that this notion covers Property 1 of my definition (in the
email below), but not Property 2.

-Olaf


On Wed, 2024-02-28 at 09:09 +0000, Franconi Enrico 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

> 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

> > 
> 
>

Received on Wednesday, 28 February 2024 09:23:15 UTC