Paul,
(This is technical input so I changed the subject line.)
commonsrdf is trying not to be "yet another toolkit".
Having a small, focused core is part of that so the minimal conversion
point is small.
Is there a way to make this a separate piece of functionality on top of
the core? Maybe something for terms <-> values.
Incidently:
https://github.com/afs/xsd4ld
which is just XSD for linked data. No RDF toolkit dependencies.
(I did wonder about a companion XSD library by ripping out/off the ARQ
xsd function support and removing it's tie to Jena - it already goes
through "NodeValue" which is value-focued, rather than term-focued.)
Andy
On 03/11/15 17:33, Paul Houle wrote:
I like that the current implementation is simple and correct, but I think
the constant conversion between primitive types and strings if you actually
tried to use this would (i) hurt speed, and (ii) hurt the perception of
speed.
Connected with that is this need to deal with type conversion when you put
data into RDF, a subject that can get pretty awkward. Jena gets it
half-right but I prototyped something that is a lot more fun to work with
at:
https://github.com/paulhoule/incubator-commonsrdf/blob/master/api/src/test/java/org/apache/commons/rdf/api/AbstractRDFTermFactoryTest.java
look at the tests towards the end of that file to see what the API looks
like.
Another thing my version does is add an "RDF" superinterface that covers
most of the other interfaces and adds a reference to a Context object that
in turn points back to an RDFContext (which used to be called the
RDFTermFactory.)
This lets you build value-added implementations that do all sorts of
things. The storage/performance cost can be brought to nothing by using a
static but you could support things like the Jena model that let you
interact with the graph in a direct way. Similarly you could make the
RDFContext configurable so if you have strong feelings about how it should
behave in corner cases it can be made so.
I'd be inclined to go another step further and add a generic parameter to
RDF and have that be some subclass of RDFContext.
Anyway if there was some serious review of this and any objections about
details can be sorted out I can imagine proposing this as the next draft.
On Tue, Nov 3, 2015 at 11:38 AM, Rob Vesse <[email protected]> wrote:
Folks
I've seen very little traffic for the last few months, while this is not
necessarily an issue in the short term it seems to reflect a general long
term trend of lack of activity after the initial flurry that occurred when
the podling was first established and put together the initial release.
I've seen a bit of discussion around adoption in other communities but
nothing that appears to have yet gone anywhere.
I am concerned that there is perhaps no longer a viable community around
this podling especially given the withdrawal of several folks and strong
objections to technical direction from others. The technical direction is
not really a problem since the ASF encourages, allows and promotes
competing
technological approaches and the Foundation itself stays out of the
technical direction of projects. However if there is no longer a viable
community here then at some point you have to start thinking about other
options e.g. retirement or leaving the Incubator for another venue I.e.
returning to GitHub
Do folks still think that it is possible to build something that will
actually be adopted by the other involved communities? Do people still
think this project has/can build the necessary momentum to move forwards
towards graduation in the long term?
Rob
