Re: Well-formedness for option 3

Indeed your property 2 is highly controversial and I have rejected it with all may energy in several past messages.
An example:
<< :w3 | :bill-clinton :related-to :hillary-rodham >> :starts 1975 .
<< :w3 | :42nd-potus :husband :1st-female-NY-senator >> :starts 1975 .
cheers
—e.

> On 28 Feb 2024, at 10:23, Olaf Hartig <olaf.hartig@liu.se> wrote:
> 
> 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:27:32 UTC