Fork me on GitHub
#rdf
<
2022-02-22
>
rickmoynihan14:02:24

Ok, I’m trying to determine what the “correct” behaviour (and whether such a thing exists) in this circumstance. And I’m wondering if anyone (in particular @quoll — who worked on SPARQL 1.1) has any ideas. Basically RDF defines a bunch of quad formats; e.g. trig/n-quads/json-ld. Of these it turns out that in all the formats the final graph clause is actually optional; in which case the triples are considered to be in the default graph. Now picture an ingestion API where there is a ?graph parameter; and a file of RDF; where the semantics for triples are “to load them into the specified ?graph“. The question is what are the best semantics for the ?graph parameter when loading a file in a quads format, where some of the statements are quads, and some are triples. Should the ?graph parameter: 1. Overwrite all statements and load them into the same ?graph 2. Leave the graphs on quads in the data alone; but apply the ?graph clause to just the triples in the file. I’ve looked at the SPARQL 1.1 graph store protocol, and it doesn’t cover this case. And I can see good arguments for each option. The stardog database in this case takes option 1.

rickmoynihan14:02:53

I can’t seem to find analogous behaviour to this specified in any of the RDF standards

quoll14:02:31

My gut reaction to this is that the API parameter defines the default graph to load into when a graph is not specified

quoll15:02:14

Since the file is saying “Here is the graph that you’re supposed to load into!”

quoll15:02:40

But when it isn’t? That’s when you fall back to “default”. And there is already precedent for setting the default in some way in the API (e.g. in queries). So that’s what I’m thinking would be happening here

quoll15:02:55

It would seem inconsistent otherwise

rickmoynihan16:02:12

Thanks a million for the reply 🙇 I think I agree with you that this is the best behaviour; and I also thought this was analogous to the default graph and how that often works. However I think the other behaviour is defensibly consistent too. i.e. “if you have a file of triples you’re putting them all into the specified graph”; which is consistent with “if you have a file of quads you’re putting them all into the specified graph”. So I’m not sure the consistency argument helps a lot… for me I think it comes down to which is the most useful behaviour, and I think that the most useful is option 2. Somebody can always find themselves in a situation where they’d prefer it worked the other way; but I think option 1 verges into transformation territory, which isn’t really it’s purpose… so it feels reasonable to require users who need transformation to just do it first.

quoll17:02:45

I was referring to “consistent” in relation to the approach that SPARQL takes. The “default” graph is a thing that can be overridden by the API. However, if a document defines a graph, then that will NEVER be overridden.

quoll17:02:37

Basically, if your data says one thing (e.g. in this case, the graph), nothing in SPARQL will ever change it

rickmoynihan17:02:27

:thumbsup: yeah that makes sense, thanks for clarifying

quoll15:02:25

If you want to override the graph specified in the file, then I think it should be an explicit “override-graph” parameter in the API

👍 1
quoll15:02:29

not something ambiguous

Kelvin19:02:11

Just pushed Flint v0.1.1 up, which consists of a number of bugfixes. (I know some people wanted to know how stable the lib is, so hopefully the fact that it's being actively maintained is reassuring.) https://github.com/yetanalytics/flint/blob/main/CHANGELOG.md

🙏 2