RE: RDF 1.2

Hi Dave,
Thank you for your comments.
] I had hoped that RDF star would give a solution for our requirement: the "asserted triple" can be subject and object without any limitation, so it can be typed.
Examples:
1) a Property (such as "Temperature") is quantifiedWith the Literal '100', and that triple is typed with the Scale 'DEGREE CELSIUS' to which that value is mapped
2) a pipe A is connectedTo pump B inlet, and that triple is typed with FLANGED CONNECTION
3) John Doe is marriedTo Maria Bloggs, and that triple is related to the place of marriage by some predicate.

But that seems problematic, including the question how to convert that to N-triples.

N-ary relationships require standardization, as do predicates.
An advantage of using n-ary relationships is that the semantics can be fully modeled once and that definition is not part of the actual triple set.
See for example https://15926.blog/templates/IN-PTYST-100.xml  where the 'internals' are defined with a graph and in first-order logic.
The actual triples are, for example: Vessel V-101 has a mass of 30.57 Metric Ton
ex:fcbfda39-4d1a-4047-b4ca-45ab8d44fca4
      rdf:type tpl:IndividualHasPropertyWithValue ;
      tpl:hasPropertyPossessor ex:847931fd-eade-4beb-b07d-a9e889611c19 ; # V-101
      tpl:hasPropertyType rdl:RDS353339 ; # MASS
      tpl:valPropertyValue "30.37"^^xsd:decimal ;
      tpl:hasScale rdl:RDS2229868 ; # METRIC TON
      meta:valEffectiveDate "2021-07-27T10:19:00Z"^^xsd:dateTime .

The graph of the internals could be simplified as shown in attached graph.

Regards, Hans 

-----Original Message-----
From: David Booth <david@dbooth.org> 
Sent: Friday, 16 February 2024 18:17
To: semantic-web@w3.org
Subject: Re: RDF 1.2

Hi Hans,

On 2/15/24 04:41, hans.teijgeler@quicknet.nl wrote:
> I follow the creation struggles of RDF 1.2 and keep being puzzled why 
> people make life so difficult(to me, that is).
> 
> May I suggest something out-of-the-box?
> 
> Use N-ary relationships as Classes, with 2 to N relations (aka 
> predicates or properties), as suggested on 12 April 2006 by Natascha 
> Noy and Alan Rector in their W3C Working Group Note "Defining N-ary 
> Relations on the Semantic Web"- 
> https://www.w3.org/TR/swbp-n-aryRelations/

I think there are two main motivations for adding a labeled-property extension to RDF, in the RDF-star effort:

  - Ease of use for common use cases.  Experience with labeled property graphs has shown that, even though they are not as general as n-ary relationships, they are good enough for many common use cases.  Special syntax makes them easier to use.

  - Standardization.  The n-ary relationship approach requires RDF authors to invent their own n-ary relationships every time they want the effect of a labeled property.  This lack of standardization has three downsides:

    1. Tools cannot recognize them as the simple labeled properties that they were intended to be.

    2. It adds cognitive burden in authoring RDF, because the author needs to learn or decide which way to model them.  (Bear in mind that there are multiple ways that n-ary relations can be modeled in RDF.)

    3. It adds cognitive burden to readers of that RDF, who need to figure out that the author was really only trying to express a labeled property, but modeled it as a class (for example).

With that said, I confess that I have mixed feelings about the RDF-star approach.  On one hand, I'm glad that folks are trying to make a common use case easier.  But on the other hand, I wish that the problem were being addressed more fundamentally, to provide a *standard* but general way to express n-ary relations, which tools and humans could easily recognize.  Labeled properties should merely be a special case.

At the 2019 W3C W3C Workshop on Web Standardization for Graph Data I briefly outlined some ways that could be done in existing RDF, in these slides excerpted from one of the sessions:
http://tinyurl.com/2019NarySlides

However, even if one of those approaches for *standardizing* n-ary relations were done, I still think it would be worth having a convenient syntax for them, to reduce tedium.  I'm still hoping for that in a future RDF-ish syntax that would also reduce other complexities in RDF usage.

Thanks,
David Booth