Re: [External] : Re: RDF is a framework, not a vocabulary

Whether << :r | :s1 :p1 :o1 >> and [ :r => rdf:s :s1 ; rdf:p :p1 ; rdf:o
:o1] are “equivalent” is debtable, but certainly the later can be
considered as being entailed by the former. The arguments for using the
(more) atomic version of a triple term <<( :s :p :o )>> were based on
considerations of getting complete results from SPARQL queries, where some
parts of the expression might not be included due to the effect of LIMIT,
or similar. That’s somewhat weakened by the use of a reifier. We do need to
be able to derive a version of a graph which does not use triple terms,
which we’ve called “Classic conformance” via an “unstar” mapping. For
example, this will be necessary for RDF Dataset Canonicalization.








*Kurt Cagle*
Editor in Chief
The Cagle Report
kurt.cagle@gmail.com
443-837-8725 <http://voice.google.com/calls?a=nc,%2B14438378725>


On Fri, Jul 12, 2024 at 1:46 PM Gregg Kellogg <gregg@greggkellogg.net>
wrote:

> On Jul 12, 2024, at 1:22 PM, Kurt Cagle <kurt.cagle@gmail.com> wrote:
>
> I'm going to continue the discussion I made this last Thursday.
>
> A reification is the definition of an anonymous node of the form:
>
> (1) [ rdf:subject :s ; rdf:predicate :p ;  rdf:object :o ; rdf:graph :g ]
>
> Which can be expanded as:
>
> (2) _:b1 rdf:subject  :s ;
>          rdf:predicate :p ;
>          rdf:object :o ;
>          rdf:graph :g ;
>          .
>
> For ease of typing (and as a recommendation) I would recommend that
> rdf:subject, etc., be shortened to rdf:s, rdf:p, etc.
>
> (3) _:b1 rdf:s  :s ;
>          rdf:p :p ;
>          rdf:o :o ;
>          rdf:g :g ;
>          .
>
> My argument for named node expressions is that these type of TURTLE
> expressions (using bracket notation, as in (1)) represent a type of node
> called an anonymous node. An anonymous node differs from a blank node in
> that a blank node is in essence locally defined to a given graph, but is
> still named relative to that particular graph (the system in essence
> creates an arbitrary substitute name when the expression is parsed, whereas
> an anonymous graph, as defined, is not named or referenceable. in Turtle
> (though it can be in SPARQL via indirection).
>
>
> The abstract syntax [1] defines Blank Nodes only. Some (all?) concrete
> syntaxes have a way to associated an identifier with a blank node, which is
> locally scoped. So, your notion of an anonymous node would be a blank node
> that was not given an identifier in the concrete syntax. Certainlly `[]`
> (the ANON terminal in Turtle, or blankNodePropertyList) is one such
> unidentified blank node, and in RDFA `_:` is also unidentified.
>
> There are been previous proposals for being able to identify a
> blankNodePropertyList with some identified blank node or IRI. Your proposed
> syntax shown below is certainly suitable for doing this. It also addresses
> some problems with the annotation syntax (e.g., `:s :p :o {| :namedNode =>
> :p1, :o1 |}`) where we were using `|` previously and creating a confusion
> with SPARQL Property Path syntax.
>
> This assumes that there are no specific semantics associated here - it's a
> parsing issue with Turtle that you have a node that is in fact not
> referenceable at all, and I believe that it underlies many of the issues
> that we are currently facing.
>
> In my proposal, I recommend a syntax (covered here) that makes it possible
> to name an anonymous node, whether with a local identifier (a bnode) or
> with a global identifier (an IRI). The syntax looks as follows:
>
> :s :p [ :namedNode => :p1 :o1; :p2 :o2 ]
>
> This has the effect of creating a new node :namedNode
> :s :p :namedNode .
> :namedNode :p1 :o1  .
> :namedNode  p2 :o2 ;
>
> Why is this important?
>
> We have a similar notation for reifications:
>
> :s :p << s1 :p1 :o1 >>.
>
> Here the reification is an anonymous node - it has no formal identifier,
> whether global or local, and consequently can only be represented
> positionally within Turtle. You can, under the current recommendations,
> create an alternate name for that reification:
>
> :s :p << :r | :s1 :p1 :o1 >>.
>
> This can also be expressed with a named node expression:
>
> ::s :p  [ :r => rdf:s :s1 ; rdf:p :p1 ; rdf:o :o1] .
>
> Both are equivalent to
>
> :s :p  :r .
> :r rdf:s :s1 ; rdf:p :p1 ; rdf:o :o1 .
>
> where :r is the reifier name.
>
>
> Whether << :r | :s1 :p1 :o1 >> and [ :r => rdf:s :s1 ; rdf:p :p1 ; rdf:o
> :o1] are “equivalent” is debtable, but certainly the later can be
> considered as being entailed by the former. The arguments for using the
> (more) atomic version of a triple term <<( :s :p :o )>> were based on
> considerations of getting complete results from SPARQL queries, where some
> parts of the expression might not be included due to the effect of LIMIT,
> or similar. That’s somewhat weakened by the use of a reifier. We do need to
> be able to derive a version of a graph which does not use triple terms,
> which we’ve called “Classic conformance” via an “unstar” mapping. For
> example, this will be necessary for RDF Dataset Canonicalization.
>
> Gregg
>
> There are many advantages to this notation (as described in my proposal at
> https://github.com/w3c/rdf-star-wg/wiki/Proposal:-Named-Node-Expressions.
>
>
>    - It provides a way of identifying a statement that can be either
>    local to the graph or in a global space.
>    - It sidesteps the whole semantics of treating a reification as a
>    specialized object: it is, but it's one that can be expressed as an extant
>    RDF structure (graph) without changing RDF itself. It does require a new
>    extension to the Turtle language, however.
>    - A reification of a triple becomes a simple annotation, and that
>    triple represented by the reification does not have to exist within the
>    associated graph.
>    - It simplifies the notation, making it possible to create structures
>    that emulate Neo4J specific statements.
>    - It makes possible local predicates (another feature of Neo4J).
>    - The same (reified triple) can be referenced by multiple reifiers for
>    different needs, without getting into the whole issue of hypergraph
>    structures (multiple subjects)
>    - Put another way, the reified triple structure is not itself a triple
>    - it makes no assertions within the graph but rather describes a
>    hypothetical triple.
>    - Given a reified triple expression in this form, a SPARQL script
>    could trivial create a construct statement that converts the expression
>    into a triple in the graph and vice-versa - turning a triple into an RT
>    Expression.
>    - It also expands readily to accommodate graph structures:
>
> Examples and use cases can be seen at
> https://github.com/w3c/rdf-star-wg/wiki/Proposal:-Named-Node-Expressions.
>
> *Kurt Cagle*
> Editor in Chief
> The Cagle Report
> kurt.cagle@gmail.com
> 443-837-8725 <http://voice.google.com/calls?a=nc,%2B14438378725>
>
>
> On Fri, Jul 12, 2024 at 6:49 AM Souripriya Das <souripriya.das@oracle.com>
> wrote:
>
>> Hi Thomas,
>>
>> > The technical argument is: it would be non-monotonic if you could
>> annotate a triple with the remark that it is not asserted.
>>
>> I'd say that that "not asserted" in the "remark" is only interpreted in
>> the context of the domain or application that the data creator is modeling
>> ... it has nothing to do with RDF's notion of assertion of a triple.
>>
>> Thanks,
>> Souri.
>>
>>
>> ------------------------------
>> *From:* Thomas Lörtsch <tl@rat.io>
>> *Sent:* Friday, July 12, 2024 4:27 AM
>> *To:* Souripriya Das <souripriya.das@oracle.com>
>> *Cc:* RDF-star WG <public-rdf-star-wg@w3.org>
>> *Subject:* [External] : Re: RDF is a framework, not a vocabulary
>>
>>
>>
>> > On 12. Jul 2024, at 10:18, Souripriya Das <souripriya.das@oracle.com>
>> wrote:
>> >
>> > I am just wondering if the recent wave of discussions is taking us
>> beyond the "framework" focus of RDF over to the territory of new
>> vocabularies that can potentially be created on top of the enhanced
>> framework of RDF.
>> >
>> > Since the goal of our WG is to determine the essential extensions to
>> the framework in current RDF that will be critical for enabling and
>> simplifying the target capabilities -- statements about statements and
>> support for duplicate triples, concerns about issues that are more
>> pertinent to development of interesting vocabularies on top of RDF1.2
>> (similar to SKOS on top of RDF1.1) should be avoided, IMHO.
>> >
>> > As long as RDF1.2 allows association of a term with a triple (or a
>> block of triples, in case of many-to-many), data creators can designate
>> such a term to belong to custom classes – :Relation, :Reification, :Myth,
>> :Nonsense, etc. –
>>
>> Those are very different terms. I agree that :Myth, :Nonsense, :Reported,
>> :Endorsed, :etc are concepts that should be treated in ontologies on top of
>> RDF. But if a statement is part of the graph, i.e. a triple, or if it’s
>> only described but not asserted, i.e a reification, is an essential aspect
>> that can’t be handled outside the core.
>> That seems very intuitive to me. The technical argument is: it would be
>> non-monotonic if you could annotate a triple with the remark that it is not
>> asserted.
>>
>> Best,
>> Thomas
>>
>>
>> >  that make sense in their domain. If there is a common set of such
>> classes that are found to be important in many domains, enthusiasts can
>> create vocabularies to capture those. Whether such classification
>> determines if a "named" (put your favorite term here) triple (or block of
>> triples) should be considered as "asserted" or not -- should be up to the
>> vocabulary designers, not our WG.
>> >
>> > Let us focus on the "framework" improvement part only and leave the
>> vocabulary aspects to data creators and enthusiasts.
>> >
>> > Hoping for timely and successful completion of RDF1.2 spec,
>> > Souri.
>>
>>
>>
>