Re: RDF API

[Stephen Allen <sa...@apache.org>]

There's also some good info on motivation at [1].  However, looking at
the RDFa working group site [2], I gather that it may be dropped due
to time constraints.  Not withstanding, there is an implementation for
ECMAScript [3] available.

-Stephen

[1] http://www.w3.org/blog/SW/2011/05/10/on_various_rdf_api_sa_b/
[2] http://www.w3.org/2010/02/rdfa/
[3] https://github.com/webr3/rdf-interfaces


On Wed, Feb 29, 2012 at 2:31 PM, Andy Seaborne <an...@apache.org> wrote:
> Hi Rahul,
>
> Interesting stuff.
>
> Just a few additions:
>
> Jena itself has a split between presentation APIs (e.g.
> Model/Statement/Resource) and core system SPI (Graph/Triple/Node - you can
> create illegal RDF at this level).  There's no reason why there can't be
> multiple presentation APIs nor indeed should it matter whether it's part for
> the core system or an additional library independent of other development.
>
> I wonder if this is a possible step to creating a neutral de facto Java API
> for RDF.  If so, I'd suggest keeping technical ambitions low as getting buy
> in from others is hard enough anyway.  It woudl be a really useful to have
> happen though.
>
>
> Non-technical:
>
> 1/ If you take contributions to your project, keep a track of everything
> (who contributed what, and when, emails, copyrights).
>
> 2/ MPL is one of Apache's "category B" licenses:
>
>  http://www.apache.org/legal/3party.html#category-b
>
> which has source code implications.
>
>        Andy
>
>
> On 29/02/12 02:05, Stephen Allen wrote:
>>
>> On Tue, Feb 28, 2012 at 10:20 AM, Rahul Parundekar
>> <rp...@gmail.com>  wrote:
>>>
>>> Hello,
>>>
>>> I was wondering if the new Jena API would be based on the W3C RDF
>>> Interfaces draft
>>> http://www.w3.org/TR/2011/WD-rdf-interfaces-20110510/
>>>
>>> If not yet, I have a bunch of Java interfaces created based on the above
>>> specifications at  http://code.google.com/p/rdf-interfaces-api/ and am
>>> willing to contribute them to the project.
>>>
>>> Thanks,
>>> Rahul
>>
>>
>>
>> Hi Rahul,
>>
>> I haven't heard of any plans to implement such an API (not to say that
>> it wouldn't happen).
>>
>> However, having read the draft, I have a few concerns with the
>> specification as it relates to an API implemented in Java.  Keep in
>> mind, these come from an RDF / SPARQL developer, who is used to
>> working in strongly typed languages like Java and C#, and has probably
>> had his mind warped from familiarity with Jena.  I also don't really
>> have much experience with RDFa.
>>
>>
>> 1) Triple interface
>>   a) No type differentiation between Named Resources, Blank Node
>> Resources and Literals in the various subject, predicate, and object
>> positions.  Instead it is represented as an attribute, which limits it
>> to runtime error checking (may not be an issue in ECMAScript, but is
>> rather ugly in strongly typed languages)
>>
>> 2) Graph interface
>>   a) There are many iterator/enumerator methods which I believe should
>> not be included.  These are available readily from other libraries
>> (such as LINQ in C#, Guava in Java, and jQuery(?) in ECMAScript).
>> These functions include toArray(), some(), every(), filter(),
>> forEach(), merge(), and the "limit" parameter of match().  Instead,
>> Graph should provide a iterator() method that allows the caller to
>> iterate over all the triples.
>>   b) match() should return an iterator instead of a Graph.  This
>> prevents having to materialize all the results if they aren't needed
>>   c) Given the above, the following interfaces don't seem necessary:
>> TripletFilter, TripletCallback, TripleAction
>>
>> 3) No concept of an RDF Dataset (a default graph + a collection of
>> named graphs) the related Quad objects
>>
>> 4) TermMap does not correspond to anything RDF specific.  I'm guessing
>> this is something from the RDFa world?  Again, maybe an external
>> library would appropriate here.
>>
>> 5) Scope seems a little limited, there is no attempt to address SPARQL
>> / SPARQL Update interfaces.  Although if the original goal was to
>> focus on ECMAScript this is understandable, since those might not be
>> exposed to the open web anyway.
>>
>>
>> Ultimately, I would guess that Jena implementing this API would be
>> weighed against a few concerns: 1) user confusion/support costs for a
>> 3rd RDF API (we already have two, Model and Graph), 2) effort to
>> implement the API, and 3) ongoing maintenance costs of the code.
>> Additionally, the specification is still in Working Draft form which
>> would make it more difficult to track and stay up to date with.
>>
>>
>> -Stephen
>
>

Re: RDF API

[Rahul Parundekar <rp...@gmail.com>]

Stephen, Andy,

Thank you for the responses.

Yes, it does seem the the interfaces API was designed for Javascript (as
Ivan mentions in [1]), but it would be great to have an implementation
independent interface that can be used. As Andy pointed out, this indeed
was the motivation for me creating the interfaces project. As far as the
use of the API is concerned, there seems to be a lot of overlap of the
Model/Statement/Resource terminologies in Jena with the
Graph/Triple/RDFNode terminologies in the RDF Interfaces specifications,
which is why I thought that it would be interesting to see if any such
interface over Jena is planned.

Privately, I have been using this interface to create a triple store
representation for my own research - A document in LinkedData (Molecule
[4]) - Saved in MongoDB

Thanks,
Rahul

[4] http://ebiquity.umbc.edu/_file_directory_/papers/178.pdf


On Thu, Mar 1, 2012 at 10:00 AM, Stephen Allen <sa...@apache.org> wrote:

> There's also some good info on motivation at [1].  However, looking at
> the RDFa working group site [2], I gather that it may be dropped due
> to time constraints.  Not withstanding, there is an implementation for
> ECMAScript [3] available.
>
> -Stephen
>
> [1] http://www.w3.org/blog/SW/2011/05/10/on_various_rdf_api_sa_b/
> [2] http://www.w3.org/2010/02/rdfa/
> [3] https://github.com/webr3/rdf-interfaces
>
>
> On Wed, Feb 29, 2012 at 2:31 PM, Andy Seaborne <an...@apache.org> wrote:
> > Hi Rahul,
> >
> > Interesting stuff.
> >
> > Just a few additions:
> >
> > Jena itself has a split between presentation APIs (e.g.
> > Model/Statement/Resource) and core system SPI (Graph/Triple/Node - you
> can
> > create illegal RDF at this level).  There's no reason why there can't be
> > multiple presentation APIs nor indeed should it matter whether it's part
> for
> > the core system or an additional library independent of other
> development.
> >
> > I wonder if this is a possible step to creating a neutral de facto Java
> API
> > for RDF.  If so, I'd suggest keeping technical ambitions low as getting
> buy
> > in from others is hard enough anyway.  It woudl be a really useful to
> have
> > happen though.
> >
> >
> > Non-technical:
> >
> > 1/ If you take contributions to your project, keep a track of everything
> > (who contributed what, and when, emails, copyrights).
> >
> > 2/ MPL is one of Apache's "category B" licenses:
> >
> >  http://www.apache.org/legal/3party.html#category-b
> >
> > which has source code implications.
> >
> >        Andy
> >
> >
> > On 29/02/12 02:05, Stephen Allen wrote:
> >>
> >> On Tue, Feb 28, 2012 at 10:20 AM, Rahul Parundekar
> >> <rp...@gmail.com>  wrote:
> >>>
> >>> Hello,
> >>>
> >>> I was wondering if the new Jena API would be based on the W3C RDF
> >>> Interfaces draft
> >>> http://www.w3.org/TR/2011/WD-rdf-interfaces-20110510/
> >>>
> >>> If not yet, I have a bunch of Java interfaces created based on the
> above
> >>> specifications at  http://code.google.com/p/rdf-interfaces-api/ and am
> >>> willing to contribute them to the project.
> >>>
> >>> Thanks,
> >>> Rahul
> >>
> >>
> >>
> >> Hi Rahul,
> >>
> >> I haven't heard of any plans to implement such an API (not to say that
> >> it wouldn't happen).
> >>
> >> However, having read the draft, I have a few concerns with the
> >> specification as it relates to an API implemented in Java.  Keep in
> >> mind, these come from an RDF / SPARQL developer, who is used to
> >> working in strongly typed languages like Java and C#, and has probably
> >> had his mind warped from familiarity with Jena.  I also don't really
> >> have much experience with RDFa.
> >>
> >>
> >> 1) Triple interface
> >>   a) No type differentiation between Named Resources, Blank Node
> >> Resources and Literals in the various subject, predicate, and object
> >> positions.  Instead it is represented as an attribute, which limits it
> >> to runtime error checking (may not be an issue in ECMAScript, but is
> >> rather ugly in strongly typed languages)
> >>
> >> 2) Graph interface
> >>   a) There are many iterator/enumerator methods which I believe should
> >> not be included.  These are available readily from other libraries
> >> (such as LINQ in C#, Guava in Java, and jQuery(?) in ECMAScript).
> >> These functions include toArray(), some(), every(), filter(),
> >> forEach(), merge(), and the "limit" parameter of match().  Instead,
> >> Graph should provide a iterator() method that allows the caller to
> >> iterate over all the triples.
> >>   b) match() should return an iterator instead of a Graph.  This
> >> prevents having to materialize all the results if they aren't needed
> >>   c) Given the above, the following interfaces don't seem necessary:
> >> TripletFilter, TripletCallback, TripleAction
> >>
> >> 3) No concept of an RDF Dataset (a default graph + a collection of
> >> named graphs) the related Quad objects
> >>
> >> 4) TermMap does not correspond to anything RDF specific.  I'm guessing
> >> this is something from the RDFa world?  Again, maybe an external
> >> library would appropriate here.
> >>
> >> 5) Scope seems a little limited, there is no attempt to address SPARQL
> >> / SPARQL Update interfaces.  Although if the original goal was to
> >> focus on ECMAScript this is understandable, since those might not be
> >> exposed to the open web anyway.
> >>
> >>
> >> Ultimately, I would guess that Jena implementing this API would be
> >> weighed against a few concerns: 1) user confusion/support costs for a
> >> 3rd RDF API (we already have two, Model and Graph), 2) effort to
> >> implement the API, and 3) ongoing maintenance costs of the code.
> >> Additionally, the specification is still in Working Draft form which
> >> would make it more difficult to track and stay up to date with.
> >>
> >>
> >> -Stephen
> >
> >
>