Re: RDF-star use cases from Amazon Neptune

I think David makes some valid points here.

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.

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

3) The question on how to nest RDF-star statements to represent the right semantics (in my marriage use case) is important. 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. 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? Also note that even the nesting in my example did not fully solve the problem at hand.

Regards,

Ora


On 12/5/21, 7:00 PM, "David Booth" <david@dbooth.org> 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

Received on Monday, 6 December 2021 10:59:14 UTC