Ross, I think you are not alone, as per this:
http://howfuckedismydatabase.com/nosql/
kc
On 11/6/13 8:54 AM, Ross Singer wrote:
Hey Karen,
It's purely anecdotal (albeit anecdotes borne from working at a company
that offered, and has since abandoned, a sparql-based triple store
service), but I just don't see the interest in arbitrary SPARQL queries
against remote datasets that I do against linking to (and grabbing) known
items. I think there are multiple reasons for this:
1) Unless you're already familiar with the dataset behind the SPARQL
endpoint, where do you even start with constructing useful queries?
2) SPARQL as a query language is a combination of being too powerful and
completely useless in practice: query timeouts are commonplace, endpoints
don't support all of 1.1, etc. And, going back to point #1, it's hard to
know how to optimize your queries unless you are already pretty familiar
with the data
3) SPARQL is a flawed "API interface" from the get-go (IMHO) for the same
reason we don't offer a public SQL interface to our RDBMSes
Which isn't to say it doesn't have its uses or applications.
I just think that in most cases domain/service-specific APIs (be they
RESTful, based on the Linked Data API [0], whatever) will likely be favored
over generic SPARQL endpoints. Are n+1 different APIs ideal? I am pretty
sure the answer is "no", but that's the future I foresee, personally.
-Ross.
0. https://code.google.com/p/linked-data-api/wiki/Specification
On Wed, Nov 6, 2013 at 11:28 AM, Karen Coyle <[email protected]> wrote:
Ross, I agree with your statement that data doesn't have to be "RDF all
the way down", etc. But I'd like to hear more about why you think SPARQL
availability has less value, and if you see an alternative to SPARQL for
querying.
kc
On 11/6/13 8:11 AM, Ross Singer wrote:
Hugh, I don't think you're in the weeds with your question (and, while I
think that named graphs can provide a solution to your particular problem,
that doesn't necessarily mean that it doesn't raise more questions or
potentially more frustrations down the line - like any new power, it can
be
used for good or evil and the difference might not be obvious at first).
My question for you, however, is why are you using a triple store for
this?
That is, why bother with the broad and general model in what I assume
is a
closed world assumption in your application?
We don't generally use XML databases (Marklogic being a notable
exception),
or MARC databases, or <insert your transmission format of choice>-specific
databases because usually transmission formats are designed to account for
lots and lots of variations and maximum flexibility, which generally is
the
opposite of the modeling that goes into a specific app.
I think there's a world of difference between modeling your data so it can
be represented in RDF (and, possibly, available via SPARQL, but I think
there is *far* less value there) and committing to RDF all the way down.
RDF is a generalization so multiple parties can agree on what data
means,
but I would have a hard time swallowing the argument that domain-specific
data must be RDF-native.
-Ross.
On Wed, Nov 6, 2013 at 10:52 AM, Hugh Cayless <[email protected]>
wrote:
Does that work right down to the level of the individual triple though?
If
a large percentage of my triples are each in their own individual graphs,
won't that be chaos? I really don't know the answer, it's not a
rhetorical
question!
Hugh
On Nov 6, 2013, at 10:40 , Robert Sanderson <[email protected]> wrote:
Named Graphs are the way to solve the issue you bring up in that post,
in
my opinion. You mint an identifier for the graph, and associate the
provenance and other information with that. This then gets ingested as
the
4th URI into a quad store, so you don't lose the provenance information.
In JSON-LD:
{
"@id" : "uri-for-graph",
"dcterms:creator" : "uri-for-hugh",
"@graph" : [
// ... triples go here ...
]
}
Rob
On Wed, Nov 6, 2013 at 7:42 AM, Hugh Cayless <[email protected]>
wrote:
I wrote about this a few months back at
http://blogs.library.duke.edu/dcthree/2013/07/27/the-
trouble-with-triples/
I'd be very interested to hear what the smart folks here think!
Hugh
On Nov 5, 2013, at 18:28 , Alexander Johannesen <
[email protected]> wrote:
But the
question to every piece of meta data is *authority*, which is the part
of RDF that sucks.
--
Karen Coyle
[email protected] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet
--
Karen Coyle
[email protected] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet
