rdf

2022-06-23T12:10:49.639229Z

@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

2022-06-23T12:22:32.684539Z

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.

2022-06-23T12:24:34.899239Z

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.

2022-06-23T12:12:01.335889Z

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

2022-06-23T12:12:50.176349Z

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