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
