W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > January 2011

Re: Generalized triples (Fwd: Non-Javascript RDF API-s?)

From: Nathan <nathan@webr3.org>
Date: Mon, 17 Jan 2011 11:43:07 +0000
Message-ID: <4D342B4B.2000500@webr3.org>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
CC: W3C RDFa WG <public-rdfa-wg@w3.org>
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.



ps: good questions :)
Received on Monday, 17 January 2011 11:43:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:23 UTC