Andy Seaborne wrote:
> On 17/01/11 10:12, Nathan wrote:
>> If we are to be successful in the definition of this API, then we need
>> to ensure the nice jQuery-for-rdf-like library works with foo-reasoner,
>> bar-store and baz-query, that users can mix and match components to get
>> their ideal setup; that innovation in libraries and specialization in
>> components is encouraged, rather than stifled.
>
> Is a corollary of this that there will be a SPARQL interface as well?
I can't see that the definition of a SPARQL interface follows directly,
but the inference is that an implementation of any query engine
(including sparql) would/should be able to use the Graph and Triple
interfaces from the RDF API and component implementations thereof.
Further, where Graphs / Triples are produced as a result of a query and
given back to a user, then it would make sense for these to be
interoperable with other components & tools imported in to the
programming environment
>> Personally, I already know the answer is yes, and all I'm hearing is
>> other library developers and users agreeing, specifically pointing to
>> good reasons why and where they are needed, and then finally
>> concluding that there's a problem because the triples they need to
>> create and use can't be serialized, aren't defined by the RDF core
>> model, and thus all mention of GTs must be hidden from the general
>> user (or words to that effect).
>
> Could you say some more on the need to be serialized, which I read as
> meaning exchanging between systems across the web. It's one thing to
> allow extensions locally, it's another to expose those extensions to
> other systems.
>
> (I'm not advocating one way or the other)
Without getting too much out of scope for this list, my stance would be
that if there is a need to shift generalized triples between
interoperable components, and RDF is a (if not the) webized date model,
then it would make sense to be able to shift generalized triples between
components that are themselves webized / networked / interacted with
"over the wire".
There are many use cases as I'm sure your aware, ranging from graph
diffs through provenance and passing by the serialization of rules and
inferences on the way. Typically, RDF (constrained) is enough to get by
when publishing statements relating to the current state of a resource,
however, as soon as you try to use those statements, infer things, add
any notion of previous state or indeed consume/use/think about
statements, then you need the generalized triples and often graph
literals too.
Bringing it back to scope, because the RDF API is a set of interfaces
for working with RDF, the scope of which would include doing all the
aforementioned things (unless we want to constrain the usage of RDF
too!), then it requires the presence of those generalized triple and
graph literal interfaces.
Best,
Nathan
ps: good questions :)