Natural representation of PG data in RDF

[klinovp]

Natural representation of PG data in RDF

[klinovp]

No, I wouldn't. It should still return :pavel unless :since/:until have some sort of temporal semantics (supporting which in the query language is a separate issue orthogonal to RDF*).

That would be useful and I fully admit this is where SA is better suited than PG, it's just not what I'm after here. Probably should have used a different example!

[klinovp]

I cannot share datasets, it's almost never possible for us. I can only give example for some of the things we see there, such as:

<< :a skos:closeMatch :b >> :score 0.9

and queries like

?x a :Type1 .
?y a :Type2 .
<< ?x skos:closeMatch ?y >> :score ?score

with subsequent filtering and aggregation on ?score.

Regarding named graphs, there's a very simple argument why we want to keep both annotated triples and named graphs. We regularly see people wondering if they should manage different parts of their data in i) separate datasets (i.e. separate physical databases inside a server instance) ii) separate named graphs inside one dataset. There are pros and cons to both. Sometimes the choice isn't clear.

So far they've been able to just take data stored in the default graph of database X and move it into a named graph inside Y. Importantly, they won't need to change queries (or apps), they only need a connection string to a different database and a different query dataset (ie. FROM in SPARQL). The latter can be defined outside of queries as defined in the SPARQL Protocol. Now, we don't want RDF* to limit that flexibility: if you want to take a bunch of triples with annotations and move them into a named graph, that should be similarly easy.

[pchampin]

Just out of curiosity, would you consider, later, to add ... :until 2019 to the triple :pavel :worksAt :Stardog?
If so, do you expect the following SPARQL query to not return :pavel?

SELECT * { ?s :worksAt :Stardog }

[lisp]

@klinovp, would it be possible to add examples to this use case. that is, concrete datasets, queries and desired results. of particular interest is the annotation of triples which are in named graphs.

[pchampin]

No, I wouldn't. It should still return :pavel unless :since/:until have some sort of temporal semantics (supporting which in the query language is a separate issue orthogonal to RDF*).

We agree on that. I just wanted to check.

Probably should have used a different example!

On the contrary, it's good that we explore all kinds of tricky examples, and clearly state what is in scope and out of scope of RDF*.

[akuckartz]

... it's good that we explore all kinds of tricky examples, and clearly state what is in scope and out of scope of RDF*.

:+💯:

[pfps]

@klinovp Are you interested in turning this use case into something that the RDF-star working group can use to help drive the development of RDF 1.2? If so please contact me or start a use case issue in https://github.com/w3c/rdf-ucr

[pfps]

@klinovp One issue in representing property graph data in RDF is determining just what the property graph can do. For example, many property graph systems can have multiple edges with the same start, end, and relationship name. What is the model that you want to capture?

[lisp]

when one carries this further, please separate the expressive capability from the representation.
the initial statement combined them, but it was not clear what that was necessary.

[pfps]

@lisp Feel free to create a use case issue yourself. Others can comment in the issue if they want. The issue can even be split if necessary.

[lisp]

@pfps, i am agnostic on the uses.
my concern is just in the implementation, from which perspective the suggested distinction would be beneficial.

[klinovp]

@klinovp One issue in representing property graph data in RDF is determining just what the property graph can do. For example, many property graph systems can have multiple edges with the same start, end, and relationship name. What is the model that you want to capture?

Hi @pfps, I must say I likely didn't think of the multiple edge use case when I wrote up the issue. I don't recall our customers/prospects being interested in that (though I might be mistaken since I no longer talk with them directly). My feeling is that if people recognise that they need to distinguish multiple relationships of the same type between the same nodes in RDF, they're more willing to reify that relationship than if they simply want to add attributes to a single relationship.

I know relatively little about property graph databases but I recall that even the neo4j book on PG databases (Jim Webber et al., iirc) has an anti-pattern section which argues against encoding entities into relationships. So I'm more interested in providing simple means for the common case where the relationship is identified only by the nodes and its type rather capturing the more general multi-relationship model which distinguishes multiple edges of the sane type.

[pfps]

@klinovp As soon as you have begin and end attributes on relationships you quickly get multiple relationships with the same three elements. Consider, for example the marriages of Richard Burton and Elizabeth Taylor, they were in a spouse relationship at two separate times, which can easily be represented in labelled property graphs but not with quoted triples, even if only one of the triples is asserted.

[klinovp]

@pfps I agree that it's easy to come up with an example of a labeled property multi-graph. However, I'm not sure the need to represent that modeling pattern in RDF 1.2 with quoted triples is strong enough to generalise the semantics of RDF graphs from sets to multisets. That'd affect a lot of things beyond quoted triples and could require some pretty fundamental implementation changes, for example, to the storage layer of existing RDF systems.

Obviously other vendors can disagree here but I think a practical translation method from LPGs to RDF 1.2 would use quoted triples for simple edges with properties and the N-ary relationship modeling pattern for multi-edges. I can see how it may still cause problems, for example, for incremental translation of changing LPG to RDF 1.2 (adding a new edge between existing nodes may require change of modeling in RDF 1.2).

[pfps]

OK, so should there be a WG use case just for the simple case? If so, please go ahead and create one in https://github.com/w3c/rdf-ucr/issues