Re: RDF-star use cases from Amazon Neptune

On 12/6/21 5:58 AM, Lassila, Ora wrote:
> I think David makes some valid points here.

Hi Ora,

> A couple of observations:
> 1) The "dependence on semantics" is an interesting issue. For sure I have built applications that very much depended on RDF's semantics (and used a reasoner). To not do so would mean to build everything from scratch, which is not what I prefer to do. So even if I technically may "control all data" in my application, it is *much* easier for me to rely on RDF than not.

Are you asserting that the use of reasoning is the sole indicator of RDF 

I don't want to jump to conclusions about your assertion, hence my question.

> 2) Related to #1, the RDF vs. LPG question, even I you reduce it to the question of "different graph representations", has to take into account the fact that there is a lot of "machinery" that comes with RDF that you would end up building yourself if you used LPGs. This does not necessarily reflect negatively on LPGs, since it may suit you just fine to build whatever mechanisms and machinery you need. I see Neptune customer use cases where one or the other approach makes more sense.

Personally, the issue of concern to me about RDF-Star and SPARQL-Star 
has little to do with LPGs being good or bad, but rather:

Why are we twisting RDF into a pretzel as a strategy for 
interoperability with LPGs?

I don't think there's a single pure LPG player that cares an iota about 
such endeavors. Why? Because they aren't about dealing with a worldview 
that matches what RDF is about, not even close.

>   If I do want mechanisms like those that RDF offers (including reasoning and well-defined semantics), I prefer to take what RDF gives me rather than rolling my own. I (and many other folks) went through a lot of effort and pain to get RDF where it is now.

Yes, which is why today we can scribble down stuff such as the following:

## Turtle Start ##

@prefix event: <> .
@prefix schema: <> .
@prefix rdf: <> .
@prefix owl: <> .
@prefix rdfs: <> .
@prefix foaf: <> .
@prefix skos: <> .
@prefix : <#> .

## Modeling Option 1 using events, since everything observed is an event.
    a :InPersonMeetingEvent ;
    schema:name "Alice meets Bob" ;
    skos:preLabel "Alice knows Bob" ;
    schema:dateCreated "2020-01-01"^^xsd:date ;
    :knows :alice, :bob ;
] schema:publisher <> .

## Modeling Option 2 notetaking metaphor.
    a :Note ;
    schema:dateCreated "2020-01-01"^^xsd:date ;
    :item [
             a :Person ;
             schema:name "Alice" ;
             :knows :bob
          ] ;
    schema:author [
                      a schema:Person;
                      schema:worksFor <>
                  ] ;
    schema:publisher <>
] .

## Modeling Option 3 notetaking metaphor.
    a :Note ;
    schema:dateCreated "2020-01-01"^^xsd:date ;
    schema:about [
                   a :Person ;
                   schema:name "Alice" ;
                   :knows :bob
] schema:author [
                      a schema:Person;
                      schema:worksFor <>
                  ] ;
   schema:publisher <>  .

## Marriage ##

    a :MarriageEvent ;
    schema:name "Alice and Bob Marriage Event"@en ;
    :hasStartDate "2020-01-01"^^xsd:date ;
    :hasBride :alice ;
    :hasGroom :bob
] schema:author [
                      a schema:Person;
                      schema:worksFor <>
                  ] ;
   schema:publisher <>  .

## Richard Burton and Elizabeth Taylor Marriages.

    a :Note ;
    :schema:about [
             a :Marriage ;
             :startYear "1964"^^xsd:Year ;
             :endYear "1974"^^xsd:Year ;
             :hasBride dbpedia:Elizabeth_Taylor ;
             :hasGroom dbpedia:Richard_Burton
] schema:publisher <> .

## Turtle End ##

> 3) The question on how to nest RDF-star statements to represent the right semantics (in my marriage use case) is important.

But Marriage isn't a problem solved by reification. A Marriage is an 
Event, and Events has clearly defined characteristics in the world 
expressed for eons in natural language.

As you know, natural language is also informed by logic.

> How you nest (that is, in which order) makes a difference, because whoever is going to query that representation has to know it. In general, I stand by my characterization of "awkward", since I want to take into account the "user experience" of querying.

Formal Language can be perceived to be awkward, hence the prevalence of 
slang. You can't turn formal language into slang.

Naturally, you can make a variety of translations of slang back into 
formal language, but you don't redefine formal language for the sake of 
slang -- as the basis for interoperability .

>   The ability to query a representation is dependent on whether there is a likelihood that you manage to write a correct query. This in addition to semantic correctness: if the query does not give you the answers you need, what good is the query?

No good at all, but I don't see how that justifies neither RDF-Star nor 
SPARQL-Star. Query solutions are very dependent on the modeling using to 
define the data they operate on etc..

LPGs usecases, are simply modeling challenges that can be handled in RDF 
without reification.

My big concern, above all else, is that an LPG surface graph is being 
eye-balled through a single RDF prism i.e., reification. How about a 
reality where those LPG examples have nothing whatsoever to do with 
reification i.e, they are basically graphs that are fundamentally devoid 
of any semantics whatsoever?

## Turtle Start ##

# I can add an owl:inverseFunctionalProperty to the mix if identity 
reconciliation becomes a concern i.e., using the right tool for that job

@prefix : <#> .


   a :Relationship ;

   :hasLabel "Some Labeled to Graph" ;

   :hasStartNode :startNode ;

   :hasEndNode :endNode

] :hasRelationshipProperty :relationshipProperty1 .

## Turtle End ##

My fundamental point is that interoperability doesn't require an 
inadvertent magnification of the core weaknesses of RDF, and by 
consequence SPARQL -- which ultimately boils down to general 
misunderstanding due to a variety of historical challenges (some 
self-made, IMHO).

Both of these standards on the very best of days are still barely 
understood by the broader public (i.e., developers, architects, decision 
makers, VCs), so why are we adding more confusion at a stage in the game 
where clarity needs to be paramount?

I don't believe LPG and RDF interoperability is a problem solved via a 
spec, especially when one party to the problem (LPG vendors) has 
absolutely no interest in any baseline semantics and will remain 
eternally allergic to the letters R-D-F.

>   Also note that even the nesting in my example did not fully solve the problem at hand.

Naturally :)


> Regards,
> Ora
> ´╗┐On 12/5/21, 7:00 PM, "David Booth" <> wrote:
>      CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>      >> On 12/3/21 6:31 AM, Pierre-Antoine Champin wrote:
>      >>> In my view, the impedance mismatch
>      >>> between RDF and PGs is not due to some arbitrary restriction on the
>      >>> RDF model. It is due to the fact that RDF is a logic, that can be
>      >>> represented as a graph, while PG is a graph data model, without any
>      >>> semantic commitment.
>      I respectfully but very much disagree.  I see RDF being used to solve
>      problems, just like PGs.  And although I like RDF's grounding in
>      semantics, I have never seen an RDF application that truly depended on
>      that semantic grounding.  Consider this:
>        - For an application in which you control all of the data, clearly
>      your application does not depend on RDF's semantics, because your
>      application could just as well CHOOSE to apply RDF's semantics.
>        - And for an application in which you do NOT control all of the data
>      -- I'm thinking here primarily of Linked Data applications -- do you
>      really think that those applications would not work if the data
>      producers had published PGs for you to consume instead of RDF (and your
>      application used PGs)?   Personally, I seriously doubt it.
>      Even with RDF's grounding in a standard semantics, every application
>      developer who uses RDF from other sources needs to look carefully at
>      that external data in advance to see if its semantics matches the needs
>      of the application.  Otherwise the application will likely produce
>      garbage output.  In other words, even though RDF itself has a standard
>      semantic grounding, that grounding is no get-out-of-jail-free card to
>      bypass the need to apply application-specific semantics.
>      I have always viewed the most significant differences between RDF and
>      PGs as being purely practical choices of graph representation.  But
>      maybe this is just a difference in perception?
>      Best wishes,
>      David Booth


Kingsley Idehen 
Founder & CEO
OpenLink Software
Home Page:
Community Support:
Weblogs (Blogs):
Company Blog:
Virtuoso Blog:
Data Access Drivers Blog:

Personal Weblogs (Blogs):
Medium Blog:
Legacy Blogs:

Profile Pages:

Web Identities (WebID):

Received on Monday, 6 December 2021 15:37:51 UTC