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

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

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Tue, 18 Jan 2011 14:26:24 +0000
Message-ID: <4D35A310.3080402@epimorphics.com>
To: nathan@webr3.org
CC: W3C RDFa WG <public-rdfa-wg@w3.org>


On 17/01/11 11:43, Nathan wrote:
> 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.

My thinking was that the RDF-API already has the interfaces for RDF 
terms to return from a SELECT query.  If the goal is portable apps, then 
just having the programmatic graph API as "jQuery-for-rdf" is incomplete 
because any app using SPARQL (query or update), including getting 
information over HTTP, isn't portable.

(there is a JSON representation of SPARQL results which (fingers 
crossed) will be REC-ized).


> 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

This argues for strict RDF at that point for interoperablity.

>>> 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).

I asked around - 4Store, for example, makes use of the fact that 
literals only occur in the object position in both indexing and query 
optimization.

>>
>> 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".

I still don't understand the need to serialize GTs.  If component foo 
works with GTs, then it's not automatic it needs to serialize them. (By 
"serialize", I mean for public use - just private use is just a 
non-standard format).

>
> 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.

GTs isn't just one set of thing.  literals-as-subject is covered by 
RDF-MT and it's only a syntax restriction that stops them. 
Bnodes-as-predicates seems to me to make sense for RDF (not OWL-DL) but 
literals-as-predicates is rather different because the relationships 
between resources should (by semweb principle) be a global name.

	Andy

>
> Best,
>
> Nathan
>
> ps: good questions :)
Received on Tuesday, 18 January 2011 14:27:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:08 GMT