I agree that Any23 could be a good home for it, and better than Commons RDF, which seems to be more focused on the basic RDF API, and I also agree that we
should keep an ongoing policy of trying to work with Commons RDF when possible. I don't think any development we have in the immediate future is of great impact
there, but as we evolve Jena's API it would be nice to do it in a way that supports Commons RDF's goal of interop, when that is practical for us.
---
A. Soroka
Claude Warren wrote on 5/13/17 6:09 AM:
Another possible home would be the any23 project.
I have some CSV reader code that handle arbitrary formats and column
names. Not sure I want to spend the time to merge it into CSV and support
it though.
On Fri, May 12, 2017 at 11:17 AM, Andy Seaborne <a...@apache.org> wrote:
On 12/05/17 07:30, Claude Warren wrote:
+1 After some thought I agree too.
== Question on the CSV stuff and perhaps a "policy" idea. ==
Does the CSV conceptually just do IO into the graph?
The CSV code reads data, not write it. It uses a fixed and simple RDF
vocabulary.
How closely are we aligned with RDF-Commons?
Does it make sense that we urge (push is too strong a word) load/save of
non-standard format (like CSV) to RDF-Commons where it might benefit a
wider audience and have more development backing?
I guess the "policy" idea is to look for synergies with RDF-Commons and
act
accordingly.
The CSV code would fit well with working over the CommonsRDF API. IMO the
biggest value of CommonsRDF is common algorithms that can run on multiple
toolkits.
Howver, CommonsRDF does not seem like a place where there is more
development resources though.
Andy
Claude
On Thu, May 11, 2017 at 3:06 PM, <aj...@apache.org> wrote:
I'm basically +1 to this. I wouldn't mind "setting a cron job" to do a
similar review every other or every three releases.
---
A. Soroka
Bruno P. Kinoshita wrote on 5/11/17 4:59 AM:
+1 to removing Fuseki1 now. And +1 for the legacy module definition and
expectations.
I'd be fine with jena-csv being removed, though I can see that being
useful for people who need to quickly ingest data into something like
Hadoop/Hive.
And jena-spatial and jena-text are modules that I plan to study someday,
just to have fun learning the ins and outs. May submit smaller commits
to
fix bits and pieces but not sure if could maintain the module.
CheersBruno
From: Andy Seaborne <a...@apache.org>
To: dev@jena.apache.org
Sent: Thursday, 11 May 2017 8:19 AM
Subject: Evolution and legacy modules
We need to do more than just add code to Jena; there needs to be a route
to removing code as well.
Starting with modules, there are some that are some that don't get the
same care and attention and without some level of maintenance, such
modules are dead weight to development.
A "legacy module"
* does not hold up a release
* may be removed from the build
(so they get swept up in a release as source only)
* may be archived
(taken out of the build and put elsewhere, such as a different repo)
The way for anyone to "unlegacy" is to give it care and attention.
Suggestions for legacy modules:
jena-sdb
jena-fuseki1
jena-csv
jena-maven-tools
jena-spatial
Others?
I don't have any plans to remove jena-sdb and it is unlikely to get in
the way. TQ do not use it.
jena-csv interferes with RIOT as it has a pseudo RDF Syntax for CSV
which is simple and not standard (not CSVW). Steps to untangle it are
in v3.3.0 and now we can make us of the pseudo RDF Syntax require
jena-csv and put it all there.
For Fuseki1, the next steps would be to remove it from the direct
mention:
* Remove explicit mention on the downloads page.
* Remove jena-fuseki1 binary from the dist/binaries/ area.
* Remove Fuseki1 from the javadoc on the website and the javadoc maker.
These can be done now, not at the next release - it's not releasing
anything.
Andy
