RE: RDF 1.2

Dear Pierre-Antoine,
Thank you for your response!
Hans

-----Original Message-----
From: Pierre-Antoine Champin <pierre-antoine@w3.org> 
Sent: Monday, 26 February 2024 19:45
To: hans.teijgeler@quicknet.nl; semantic-web@w3.org; 'David Booth' <david@dbooth.org>
Subject: Re: RDF 1.2

Dear Hans,

(disclaimer: the following is my interpretation of what the consensus of the working group is at this time, but the discussions are still ongoing, and my interpretation may be biased)

On 17/02/2024 16:36, hans.teijgeler@quicknet.nl wrote:
> 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.
What you describe would be represented in Turtle 1.2 like this:

     <#room1> ex:temperature 100 {| ex:scale ex:DegreeCelsius |}.
     <#pipeA> ex:connectedTo <#inletB> {| a ex:FlangedConnection |}.
     <#john> ex:marriedTo <#maria> {| ex:location wd:Q23768 |}.
>
> But that seems problematic, including the question how to convert that to N-triples.
The representation to N-triples is not entirely settled yet, but the current consensus is that it would look somewhat like that (with dummy short IRIs instead of real ones).

     <base:#room1> <ex:temperature> "100"^^<xsd:integer> .
     _:t1 <rdf:hasTriple> <( <base:#room1> <ex:temperature> "100"^^<xsd:integer> )>.
     _:t1 <ex:scale> <ex:DegreeCelsius> .
    # and likewise for the other annotated triples.

The object of the 2nd triple above (between <( .. )>) is a new kind of RDF terms (besides IRIs, literals and blank nodes).

>
> 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.
This kind of representation is already possible in RDF 1.1 and will of course still be possible in RDF 1.2. Using the annotation pattern (my examples above) or the N-ary relation pattern (your example above) is a matter of preference and trade-off:
* the annotation pattern gives more importance to two participants of the relationship (the subject and object), while the other participants (the temperature scale, the wedding location) are considered secondary ;
* the N-ary pattern, on the other hand, makes all participants equal.

   best

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

Received on Tuesday, 27 February 2024 09:43:13 UTC