Fork me on GitHub
#rdf
<
2022-06-23
>
Al Baker12:06:49

@rickmoynihan it wouldn't be a silver bullet for sure -- but take like Stardog's stored query = REST service approach. Having this response format option would make it look like vanilla JSON service... this URL just happens to run this SPARQL query, and you get your response out as something easy to deal with. We do that similar type of translation stuff for graphql in Stardog already, and it's alright - plenty of folks are using it, even in combo w/ stuff like Apollo. But you still wind up with URI or prefixes in the mix

rickmoynihan12:06:32

Yeah that’s quite neat… My only real problem with prefixes in these contexts for API’s is handling them in a non-breaking manner with data from an open world. i.e. a new URI term appears, and consumers adopt it by it’s full URI; but it stands out like a sore thumb when other identifiers have prefixes registered… so you add a prefix for it, but then break existing consumers.

rickmoynihan12:06:34

So then you have to ask what is the point. You might as well just use the URIs; though there are more dimensions to this decision for sure.

Al Baker12:06:01

my original use case for this was I think the early verions of Gephi didn't deal with URIs nicely, so you'd load it up but then you'd get URLs w/ poor UX on truncating, so the whole thing was accurate on shape/colors, but you had to double click to see what was really going on, since every label was effectively the same (the first 16 characters of the URI, then truncated with a few dots or whatever it was).

Al Baker12:06:50

revisiting Gephi is on my list... I've been wanting one of those larger scale views of the graph, that wasn't necessarily readable, but would give you maybe edge/class colorization and you could get a visual indication on how much of what was present