Ethan, thanks, it's good to have examples.
I'd say that for "simple linking" SPARQL may not be necessary, perhaps
should be avoided, but IF you need something ELSE, say a query WHERE you
have conditions, THEN you may find that a query language is needed.
kc
On 11/6/13 9:14 AM, Ethan Gruber wrote:
I think that the answer to #1 is that if you want or expect people to use
your endpoint that you should document how it works: the ontologies, the
models, and a variety of example SPARQL queries, ranging from simple to
complex. The British Museum's SPARQL endpoint (
http://collection.britishmuseum.org/sparql) is highly touted, but how many
people actually use it? I understand your point about SPARQL being too
complicated for an API interface, but the best examples of services built
on SPARQL are probably the ones you don't even realize are built on SPARQL
(e.g., http://numismatics.org/ocre/id/ric.1%282%29.aug.4A#mapTab). So on
one hand, perhaps only the most dedicated and hardcore researchers will
venture to construct SPARQL queries for your endpoint, but on the other,
you can build some pretty visualizations based on SPARQL queries conducted
in the background from the user's interaction with a simple html/javascript
based interface.
Ethan
On Wed, Nov 6, 2013 at 11:54 AM, Ross Singer <rossfsin...@gmail.com> 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 <li...@kcoyle.net> 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 <philomou...@gmail.com>
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 <azarot...@gmail.com>
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 <philomou...@gmail.com>
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 <
alexander.johanne...@gmail.com> wrote:
But the
question to every piece of meta data is *authority*, which is the
part
of RDF that sucks.
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet
