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

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).

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.

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.
>
>
>