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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >> >> -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
