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/02/14 12:26:19 UTC
Clearing up old branches
We have some old branches:
2012-05-09 refs/remotes/origin/jena-owl2
2013-01-31 refs/remotes/origin/streaming-update
2015-04-22 refs/remotes/origin/JENA-380
2015-05-22 refs/remotes/origin/add-contract-tests
2015-07-08 refs/remotes/origin/jena2
2015-08-06 refs/remotes/origin/jena-text-cache
2016-01-28 refs/remotes/origin/JENA-507
2017-01-11 refs/remotes/origin/ThreadPerGraphDataset
+ master and HEAD.
where the date is the latest commit.
(that's from
git for-each-ref \
--sort='committerdate:short' \
--format=' %(committerdate:short)%09%(refname)' \
refs/remotes
and help from StackOverflow).
All but "jena2" and "ThreadPerGraphDataset" look like they can be deleted.
---- Investigation
"jena-owl2" - has no activity.
It probably creates a false impression - better to delete it.
"streaming-update"
Refers to JENA-330 which is closed.
The branch can be deleted.
"JENA-380" - "Migrate core tests to junit4"
This is done.
The branch can be deleted.
We need to close the JIRA.
"add-contract-tests"
This is done.
The branch can be deleted.
Jena2 ends at branch "jena2" 2015-07-08 (with release 2015-07-29) so
everything before is very out of date.
"jena-text-cache"
Refers to JENA-999 which is closed so this looks like it is finished with.
The branch can be deleted.
"JENA-507"
"Add support for Leviathan extension functions to ARQ"
This is done. The branch can be deleted.
Close JIRA.
"ThreadPerGraphDataset"
Recent.
--------------------
That leaves:
2015-07-08 refs/remotes/origin/jena2
2017-01-11 refs/remotes/origin/ThreadPerGraphDataset
2017-02-12 refs/remotes/origin/HEAD
2017-02-12 refs/remotes/origin/master
We have tools - github, clones and pull requests - that make discussion
and review easier. For example, a PR gives a cumulative view of all
commits as well as all commits.
Nowadays, I think it is better to develop new capabilities through
clones and dynamic PRs and better to keep the main code repository as
focused on the main line of development so I propose deleting branches
and closing JIRA as noted above.
Comments?
Andy
Re: Clearing up old branches
Posted by Andy Seaborne <an...@apache.org>.
Done.
git branch -r ==>
origin/HEAD -> origin/master
origin/ThreadPerGraphDataset
origin/jena2
origin/master
and recorded in JENA-1289 (with latest hashes for each branch).
Andy
On 14/02/17 12:26, Andy Seaborne wrote:
> We have some old branches:
>
> 2012-05-09 refs/remotes/origin/jena-owl2
> 2013-01-31 refs/remotes/origin/streaming-update
> 2015-04-22 refs/remotes/origin/JENA-380
> 2015-05-22 refs/remotes/origin/add-contract-tests
>
> 2015-07-08 refs/remotes/origin/jena2
>
> 2015-08-06 refs/remotes/origin/jena-text-cache
> 2016-01-28 refs/remotes/origin/JENA-507
> 2017-01-11 refs/remotes/origin/ThreadPerGraphDataset
>
> + master and HEAD.
>
> where the date is the latest commit.
>
> (that's from
>
> git for-each-ref \
> --sort='committerdate:short' \
> --format=' %(committerdate:short)%09%(refname)' \
> refs/remotes
>
> and help from StackOverflow).
>
> All but "jena2" and "ThreadPerGraphDataset" look like they can be deleted.
>
> ---- Investigation
>
> "jena-owl2" - has no activity.
> It probably creates a false impression - better to delete it.
>
> "streaming-update"
> Refers to JENA-330 which is closed.
> The branch can be deleted.
>
> "JENA-380" - "Migrate core tests to junit4"
> This is done.
> The branch can be deleted.
> We need to close the JIRA.
>
> "add-contract-tests"
> This is done.
> The branch can be deleted.
>
> Jena2 ends at branch "jena2" 2015-07-08 (with release 2015-07-29) so
> everything before is very out of date.
>
> "jena-text-cache"
> Refers to JENA-999 which is closed so this looks like it is finished with.
> The branch can be deleted.
>
> "JENA-507"
> "Add support for Leviathan extension functions to ARQ"
> This is done. The branch can be deleted.
> Close JIRA.
>
> "ThreadPerGraphDataset"
> Recent.
>
>
> --------------------
> That leaves:
>
> 2015-07-08 refs/remotes/origin/jena2
> 2017-01-11 refs/remotes/origin/ThreadPerGraphDataset
> 2017-02-12 refs/remotes/origin/HEAD
> 2017-02-12 refs/remotes/origin/master
>
> We have tools - github, clones and pull requests - that make discussion
> and review easier. For example, a PR gives a cumulative view of all
> commits as well as all commits.
>
> Nowadays, I think it is better to develop new capabilities through
> clones and dynamic PRs and better to keep the main code repository as
> focused on the main line of development so I propose deleting branches
> and closing JIRA as noted above.
>
> Comments?
>
> Andy
Re: Clearing up old branches
Posted by Rob Vesse <rv...@dotnetrdf.org>.
Leviathan also includes some extension aggregates. At the time branch was originally created there was no support for this in Jena so I left the branch open. Those extension aggregates could probably be added separately at a later date although I think Andy already added some equivalent aggrega equivalent aggregates as part of unrelated work
On 14/02/2017 12:26, "Andy Seaborne" <an...@apache.org> wrote:
"JENA-507"
"Add support for Leviathan extension functions to ARQ"
This is done. The branch can be deleted.
Close JIRA.
Re: Clearing up old branches
Posted by Osma Suominen <os...@helsinki.fi>.
14.02.2017, 14:26, Andy Seaborne kirjoitti:
> "jena-text-cache"
> Refers to JENA-999 which is closed so this looks like it is finished with.
> The branch can be deleted.
+1 - verified that this is the case
> Nowadays, I think it is better to develop new capabilities through
> clones and dynamic PRs and better to keep the main code repository as
> focused on the main line of development so I propose deleting branches
> and closing JIRA as noted above.
+1
-Osma
--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suominen@helsinki.fi
http://www.nationallibrary.fi
Re: Clearing up old branches
Posted by "A. Soroka" <aj...@virginia.edu>.
> On Feb 15, 2017, at 4:31 PM, Andy Seaborne <an...@apache.org> wrote:
> On 14/02/17 15:52, A. Soroka wrote:
<snipped>
>> [Fedora Commons] does offer a lot more, but it might still be scoped enough and quickly scalable enough for your immediate needs. Obviously, even though I commit for it, it doesn't do all my LDP needs because I am here talking about doing another impl! :)
>
> What needs do you see here?
It's more that as Osma noticed, Fedora does a great deal that isn't of use or interest to everyone. Within that project I tried to move forward an API specification that would allow for alternative (more minimal) implementations, but until that comes to fruition, it would be nice to have something available that is much, much lighter-weight and SPARQL-equipped out of the box and supported by a lively community (e.g. this one! :grin:).
> The main choice is designing the URL space - making a SPARQL endpoint not look like an LDP resource. You could snoop deeper into the request iof you want namespace overlap. That may happen automatically as direct-named GSP resources. But there again, it may be too clever and no GSP configured and use JAX-RS be a lot easier to build.
One question is whether there is a one-to-one dataset <=> LDP service matching. I'm not sure that has to be the case, or even should be.
> Can LDP-NR be handled by web server static resource handling (and maybe a filter if you want to chnage the HTTP header)?
Something like that. I was also thinking about bringing something like Apache Camel for that purpose because you might have a lot of different sources for bitstreams. From Jena's POV, I think we can just leave that up to the integrator, yes?
---
A. Soroka
The University of Virginia Library
Re: Clearing up old branches
Posted by Andy Seaborne <an...@apache.org>.
On 14/02/17 15:52, A. Soroka wrote:
>> On Feb 14, 2017, at 10:42 AM, Osma Suominen
>> <os...@helsinki.fi> wrote: 14.02.2017, 17:03, A. Soroka
>> kirjoitti:
>>> Osma, you might want to take a look at Fedora Commons:
>>>
>>> http://fedorarepository.org/
>>>
>>> which is actually the project through which I came to work on
>>> Jena. It might be a good option for you.
>>
>> Thanks for the tip. It was on my radar, but seemed to have a
>> different focus than what I was looking for, far more than just a
>> LDP triple store. I will take a closer look!
>
> It does offer a lot more, but it might still be scoped enough and
> quickly scalable enough for your immediate needs. Obviously, even
> though I commit for it, it doesn't do all my LDP needs because I am
> here talking about doing another impl! :)
What needs do you see here?
>
>>> The biggest qualm I have about an LDP implementation for Jena is
>>> that many people may want to store opaque bitstream resources
>>> (what LDP calls LDP-NR, "non-RDF" resources) in their LDP
>>> instance. That seems outside the bounds for Jena.
>>
>> Right, that's not really Jena. However, a RDF-only LDP
>> implementation would, IMHO, make sense and could probably still be
>> very useful.
>
> Well, we have pretty almost all the parts in place. Andy, do you
> think this would make sense as a kind of "extension" for Fuseki or
> better as an independent component? I'm inclined to the latter, in
> hopes that a lot of the HTTP machinery could be handled very simply
> by an off-the-shelf JAX-RS library, and I am already familiar with
> JAX-RS, whereas Fuseki's HTTP machinery is a bit opaque to me at the
> moment.
JAX-RS for the LDP side makes sense. The URL patterns can be fixed.
Fuseki deals with changes of the URLs served as it's running because
datasets get created in the UI and it works as a servlet filter to spot
request to a dataset, then directs requests to a single servlet to
execute all requests.
The filter looks in a registry to see if a request URL matches a
registered datasets eslse it falls though to static servlets (the admin
operations) and static page handling.
Fuseki request are all handled by one servlet. It happens to route to
other servlets which means some other system can pick-and-choose which
SPARQL features to provide. The actually operations are
semi-independent of servet-ness in case the core engine were to be used
in a non_HTTP context.
Embedded Fuseki routes "/*" to the filter.
All the stuff about "HttpAction" is to have a tracking object passed
tough requests. It was a good choice of design opattern.. Servlet
attributes would be much too low level building block and have no
structure specific to the usage.
So adding that to the JAX-RS dispatch for LDP should be an easy (!) to
add SPARQL over the LDP resources.
The main choice is designing the URL space - making a SPARQL endpoint
not look like an LDP resource. You could snoop deeper into the request
iof you want namespace overlap. That may happen automatically as
direct-named GSP resources. But there again, it may be too clever and
no GSP configured and use JAX-RS be a lot easier to build. Can LDP-NR be
handled by web server static resource handling (and maybe a filter if
you want to chnage the HTTP header)?
Andy
>
>
>
> --- A. Soroka The University of Virginia Library
>
Re: Clearing up old branches
Posted by "A. Soroka" <aj...@virginia.edu>.
> On Feb 14, 2017, at 10:42 AM, Osma Suominen <os...@helsinki.fi> wrote: 14.02.2017, 17:03, A. Soroka kirjoitti:
>> Osma, you might want to take a look at Fedora Commons:
>>
>> http://fedorarepository.org/
>>
>> which is actually the project through which I came to work on Jena. It might be a good option for you.
>
> Thanks for the tip. It was on my radar, but seemed to have a different focus than what I was looking for, far more than just a LDP triple store. I will take a closer look!
It does offer a lot more, but it might still be scoped enough and quickly scalable enough for your immediate needs. Obviously, even though I commit for it, it doesn't do all my LDP needs because I am here talking about doing another impl! :)
>> The biggest qualm I have about an LDP implementation for Jena is that many people may want to store opaque bitstream resources (what LDP calls LDP-NR, "non-RDF" resources) in their LDP instance. That seems outside the bounds for Jena.
>
> Right, that's not really Jena. However, a RDF-only LDP implementation would, IMHO, make sense and could probably still be very useful.
Well, we have pretty almost all the parts in place. Andy, do you think this would make sense as a kind of "extension" for Fuseki or better as an independent component? I'm inclined to the latter, in hopes that a lot of the HTTP machinery could be handled very simply by an off-the-shelf JAX-RS library, and I am already familiar with JAX-RS, whereas Fuseki's HTTP machinery is a bit opaque to me at the moment.
---
A. Soroka
The University of Virginia Library
Re: Clearing up old branches
Posted by Osma Suominen <os...@helsinki.fi>.
14.02.2017, 17:03, A. Soroka kirjoitti:
> Osma, you might want to take a look at Fedora Commons:
>
> http://fedorarepository.org/
>
> which is actually the project through which I came to work on Jena. It might be a good option for you.
Thanks for the tip. It was on my radar, but seemed to have a different
focus than what I was looking for, far more than just a LDP triple
store. I will take a closer look!
> The biggest qualm I have about an LDP implementation for Jena is that many people may want to store opaque bitstream resources (what LDP calls LDP-NR, "non-RDF" resources) in their LDP instance. That seems outside the bounds for Jena.
Right, that's not really Jena. However, a RDF-only LDP implementation
would, IMHO, make sense and could probably still be very useful.
-Osma
--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suominen@helsinki.fi
http://www.nationallibrary.fi
Re: Clearing up old branches
Posted by "A. Soroka" <aj...@virginia.edu>.
Osma, you might want to take a look at Fedora Commons:
http://fedorarepository.org/
which is actually the project through which I came to work on Jena. It might be a good option for you.
The biggest qualm I have about an LDP implementation for Jena is that many people may want to store opaque bitstream resources (what LDP calls LDP-NR, "non-RDF" resources) in their LDP instance. That seems outside the bounds for Jena.
---
A. Soroka
The University of Virginia Library
> On Feb 14, 2017, at 9:54 AM, Osma Suominen <os...@helsinki.fi> wrote:
>
> 14.02.2017, 16:43, A. Soroka kirjoitti:
>
>> Thoughts? Is anyone else interested in bring an optional LDP component to Fuseki (or perhaps independently of Fuseki, a la jena-ldp)?
>
> I think a LDP feature in Fuseki (or outside) would be very good to have, even if I don't currently have a specific use case in mind. In fact, I looked at the existing LDP implementations a while ago, since I need a platform for publishing a relatively large amount (~40M triples to start with) of bibliographic Linked Data. I mostly liked the LDP API but was a bit disappointed with the implementations. Apache Marmotta looked very promising, but they seem to have problems with developer resources and making a release. Also the performance was not very good as the PostgreSQL based storage layer is pretty heavy.
>
> At the moment I have put LDP aside and I'm instead considering using the RDF HDT suite of tools, for example hdt-fuseki (a version of Fuseki that can serve read-only data directly from HDT files), and then building the necessary APIs on top of that (perhaps using Elda).
>
> -Osma
>
> --
> Osma Suominen
> D.Sc. (Tech), Information Systems Specialist
> National Library of Finland
> P.O. Box 26 (Kaikukatu 4)
> 00014 HELSINGIN YLIOPISTO
> Tel. +358 50 3199529
> osma.suominen@helsinki.fi
> http://www.nationallibrary.fi
Re: Clearing up old branches
Posted by Osma Suominen <os...@helsinki.fi>.
14.02.2017, 16:43, A. Soroka kirjoitti:
> Thoughts? Is anyone else interested in bring an optional LDP component to Fuseki (or perhaps independently of Fuseki, a la jena-ldp)?
I think a LDP feature in Fuseki (or outside) would be very good to have,
even if I don't currently have a specific use case in mind. In fact, I
looked at the existing LDP implementations a while ago, since I need a
platform for publishing a relatively large amount (~40M triples to start
with) of bibliographic Linked Data. I mostly liked the LDP API but was a
bit disappointed with the implementations. Apache Marmotta looked very
promising, but they seem to have problems with developer resources and
making a release. Also the performance was not very good as the
PostgreSQL based storage layer is pretty heavy.
At the moment I have put LDP aside and I'm instead considering using the
RDF HDT suite of tools, for example hdt-fuseki (a version of Fuseki that
can serve read-only data directly from HDT files), and then building the
necessary APIs on top of that (perhaps using Elda).
-Osma
--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suominen@helsinki.fi
http://www.nationallibrary.fi
Re: jena-ldp
Posted by "A. Soroka" <aj...@virginia.edu>.
> On Feb 15, 2017, at 4:10 PM, Andy Seaborne <an...@apache.org> wrote:
>
>
> Then there are a couple of comments about design and jena-ldp overall. I took away from that that ThreadPerGraphDataset is in-progress - I think it would be better to know it is the right design for whatever it's use case is before putting into a jena release. It gives more freedom to change without worrying about incompatibility.
>
> Once released there is an obligation which can be limiting (despite any words around it to say "may change").
Well, the code as it stands is (I think) okay-- but where does it stand within Jena? :grin:
I'm going to close that PR and move the branch over to my Github clone. There are at least two possibilities here: evolve it towards some kind of jena-ldp, or expand it to try to tackle variable lock regions and a more general in-memory multiwriter setup. Either deserve their own threads of discussion.
---
A. Soroka
The University of Virginia Library
jena-ldp
Posted by Andy Seaborne <an...@apache.org>.
On 14/02/17 14:43, A. Soroka wrote:
>
>> On Feb 14, 2017, at 7:26 AM, Andy Seaborne <an...@apache.org> wrote:
>>
>> Nowadays, I think it is better to develop new capabilities through clones and dynamic PRs and better to keep the main code repository as focused on the main line of development so I propose deleting branches and closing JIRA as noted above.
>
> +1
>
> I have just rebased ThreadPerGraphDataset (sorry about the slew of commit msgs!).
>
> I would like to land that branch, but we did not come to a conclusion here:
>
> https://github.com/apache/jena/pull/204
>
> that I could find about how to do that. Andy remarked:
>
>> \u2022 "Small things" being curated go into a general jena-extras/jena-wip/jena-labs/jena-optional module with the idea that that is just while they mature, Downside: things go into that module and don't progress.
>> \u2022 At the other end of the spectrum, this is a step for jena-ldp so to get attention on that, use that name. Downside: over selling.
>> \u2022 Specific for this one thing: jena-writer-dsg, a name for the write-centric dataset. Downside: does not connect to LDP usage.
>
>
Then there are a couple of comments about design and jena-ldp overall.
I took away from that that ThreadPerGraphDataset is in-progress - I
think it would be better to know it is the right design for whatever
it's use case is before putting into a jena release. It gives more
freedom to change without worrying about incompatibility.
Once released there is an obligation which can be limiting (despite any
words around it to say "may change").
> Thoughts? Is anyone else interested in bring an optional LDP component to Fuseki (or perhaps independently of Fuseki, a la jena-ldp)?
Its easy enough to build a Fuseki with more code loaded into it. That's
what [1] does. Copy the Fuseki shaded POM pattern.
Or put the Fuseki combined jar on the classpath (-cp, not -jar) =- that
works as well. As Fuseki has all the cmds inside it, it's a convenient
way to work on a remote server.
Andy
[1]
https://github.com/afs/mantis/blob/master/fuseki-tdb2/pom.xml
>
> ---
> A. Soroka
> The University of Virginia Library
>
Re: Clearing up old branches
Posted by "A. Soroka" <aj...@virginia.edu>.
> On Feb 14, 2017, at 7:26 AM, Andy Seaborne <an...@apache.org> wrote:
>
> Nowadays, I think it is better to develop new capabilities through clones and dynamic PRs and better to keep the main code repository as focused on the main line of development so I propose deleting branches and closing JIRA as noted above.
+1
I have just rebased ThreadPerGraphDataset (sorry about the slew of commit msgs!).
I would like to land that branch, but we did not come to a conclusion here:
https://github.com/apache/jena/pull/204
that I could find about how to do that. Andy remarked:
> • "Small things" being curated go into a general jena-extras/jena-wip/jena-labs/jena-optional module with the idea that that is just while they mature, Downside: things go into that module and don't progress.
> • At the other end of the spectrum, this is a step for jena-ldp so to get attention on that, use that name. Downside: over selling.
> • Specific for this one thing: jena-writer-dsg, a name for the write-centric dataset. Downside: does not connect to LDP usage.
Thoughts? Is anyone else interested in bring an optional LDP component to Fuseki (or perhaps independently of Fuseki, a la jena-ldp)?
---
A. Soroka
The University of Virginia Library