incubator-any23-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmür <>
Subject Re: Zhugu Proposal
Date Fri, 06 Jul 2012 08:21:40 GMT
On Thu, Jul 5, 2012 at 11:12 AM, Andy Seaborne <> wrote:
This proposal combines two things if I read it right - I'm not sure linking
> them is the best approach.
> One strand is a home for sparQLed codebase (at least the browser-side
> editor part, unclear about the analysis engine part).  The issue I see is
> that it is based, in part, on another open source project "Flint". It may
> look like a fork, a derived work, or something else.  The Flint community
> may even be willing to make an ASF grant - I don't know them.

Yes that's true. I'm not sure how much SparQLed is a fork of flint, if it
merely integrate flint or if changed the flint codebase. Licensewise it's
unproblematic because of flint is MIT Licensed, but if we could the flint
community participating to Zhugu this would be great.

> The other strand is a consolidation of other open source and packaging
> with maven. I'd describe this part of Zhugu as a collection libraries, not
> frame it as an application because "application" to me is something an end
> user can use.

Indeed I was insecure about which term to use, using both terms seemed a
bit long winded. I thought to emphasize more tools like createjs[1] and
sparQLed which are frontend applications or at least more pervasive
libraries than something like VIE or rdfquery. The user might not see that
two different applications use rdfquery on the other hand the user might
not see that two sparQLed web-apps use a different backend so she might
consider sparQLed to be the app. But I'm happy to use the term library if
this leads to less misunderstandings.

> It is certainly useful to provide a consistent, tested cut of javascript
> libraries so developers get a collection that works together - but I
> wouldn't want to downplay the amount of work this needs to be complete
> because of needing the transitive closure effect e.g rdfquery (last
> released 2009), depends on jQuery and jQuery isn't in maven.

I think we need to be pragmatic about this and start with some concrete
apps/libraries like create.js and in a first step just integrate their
dependencies. In a second step we can care about the modularization and
mavenization of the decency chain. It's not a perfect world but its better
than the current situations where different projects just have bunches js
files somewhere in their resource forks.

To come back to your doubt that linking the two aspects is a good approach:
I think that while at some point it might be good to separate things it
would be now a first project for client side semantic libraries and having
one community around this is challenging enough. The mavenization of
js-project is similar to the providing of OSGi bundles from existing java
libraries, the latter is currently done in many projects like service-mix,
sling and clerezza and it's often not clear where the bundleized version of
a certain library can be found. By putting the packaging of third party
libraries as a goal into the Zhugu proposal we have a place that dedicates
to this which prevents just doing the mavenization where it is first
needed, the hope is that the various projects depending on these artifacts
would contribute to Zhugu if they need an newer version rather than
creating a new mavenization (like this is frequent for OSGi bundleizations).

Doe this make sense?



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message