You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2017/05/10 20:19:15 UTC
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
Re: Evolution and legacy modules
Posted by aj...@apache.org.
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 <an...@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 <an...@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: Evolution and legacy modules
Posted by Claude Warren <cl...@xenei.com>.
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 <an...@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 <an...@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
Re: Evolution and legacy modules
Posted by Andy Seaborne <an...@apache.org>.
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 <an...@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
>>>
>>>
>>>
>>>
>>>
>>>
>
>
Re: Evolution and legacy modules
Posted by Claude Warren <cl...@xenei.com>.
+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?
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.
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 <an...@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
Re: Evolution and legacy modules
Posted by aj...@apache.org.
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 <an...@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
>
>
>
>
>
Re: Evolution and legacy modules
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
+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 <an...@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