Named Graphs
27 views
Skip to first unread message
arndtn
Jun 7, 2010, 1:00:32 PM6/7/10
to androjena
Dear Lorenzo Carrara and Giorgio Orsi,
first, thank you for this jena port to android, after including all
necessary dependencies I have my first working lines of code, which
use androjena :-)
But now I have an other question: Does AndoJena support Named Graphes?
Or do you plan to port the ng4j [1] jena-extension to android?
Natanael
[1] http://www4.wiwiss.fu-berlin.de/bizer/ng4j/
first, thank you for this jena port to android, after including all
necessary dependencies I have my first working lines of code, which
use androjena :-)
But now I have an other question: Does AndoJena support Named Graphes?
Or do you plan to port the ng4j [1] jena-extension to android?
Natanael
[1] http://www4.wiwiss.fu-berlin.de/bizer/ng4j/
lencinhaus
Jun 7, 2010, 3:34:10 PM6/7/10
to androjena
Thank you Natanael.
By now, Androjena comprises *just* Jena: no sparql (ARQ), no
persistence (SDB or TDB), no external reasoners (DIG), nothing else
than the core Jena 2.6.2 codebase.
That said, Androjena alone (as Jena itself) doesn't support named
graphs either.
I've taken a look to the ng4j library you mentioned, but sadly it's
not android-compatible out of the box. The whole library relies on
some J2SE features that are absent in Android's classpath; besides,
depending on the feature, it relies on other Jena extensions and
external libraries that have not been ported to Android by now. I'll
list the unmet dependencies below; maybe someday we (or someone else)
will port some or all of these features/libraries, but it's not
scheduled for the near future (maybe ARQ, we'll see :)
J2SE dependencies:
- javax.transform API: it's used to translate XML between DOM
documents and SAX handlers and streams. Jena used it too, so we had to
develop some simple replacement classes and change Jena code to use
them (they could be used with ng4j too, with some refactoring). Note
that the latest Android API (level 8, intoduced with the 2.2 "Froyo"
release) now includes the transform API; anyway, to keep Androjena
compatible with older releases of Android, we won't rely on that
support. If you plan to use the ng4j library only on 2.2 or newer
devices, then forget about this dependency.
Jena dependencies:
- ARQ: for SPARQL queries over named graphs.
External libraries:
- bouncy castle crypto API (seems that someone already used it in
android or that android classpath includes part of the library, so
chances are that it works ootb)
- ANTLR (needed for the TriG parser, so maybe givin up that feature
could eliminate this dependency)
- Apache commons codec (needed for Base64 support, we already included
in Androjena a replacement for that, taken from Apache Xerces
implementation)
- Apache log4j and Apache commons logging (sadly ng4j uses log4j and
apache logging directly, instead of slf4j like Jena did) (because we
have ported slf4j already, see build docs)
- Apache Axis (needed for UUID generation and other web-service stuff,
maybe givin up some features of ng4j could eliminate this dependency
too)
- Apache Xerces (was used in Jena too, can be replaced with Android
parsers, at the cost of some refactoring).
- NekoHTML (which depends on Xerces too)
- God knows what more :)
As you can see, the task is all but trivial. The huge availability of
libraries is one of the coolest aspects of Java but, from an Android
perspective, is also its most painful issue, because everything relies
on everything, with Apache as a foundation. It's a matter of time
before the most important libraries will be ported; in the meantime we
hope to open the door to some mobile semantics :)
One last thing: did you try the latest androjena test application on
your HTC Magic? If not, please do it (and let it send us the results):
it would really help us figure out Androjena support over different
devices.
Bye,
lorenzo
By now, Androjena comprises *just* Jena: no sparql (ARQ), no
persistence (SDB or TDB), no external reasoners (DIG), nothing else
than the core Jena 2.6.2 codebase.
That said, Androjena alone (as Jena itself) doesn't support named
graphs either.
I've taken a look to the ng4j library you mentioned, but sadly it's
not android-compatible out of the box. The whole library relies on
some J2SE features that are absent in Android's classpath; besides,
depending on the feature, it relies on other Jena extensions and
external libraries that have not been ported to Android by now. I'll
list the unmet dependencies below; maybe someday we (or someone else)
will port some or all of these features/libraries, but it's not
scheduled for the near future (maybe ARQ, we'll see :)
J2SE dependencies:
- javax.transform API: it's used to translate XML between DOM
documents and SAX handlers and streams. Jena used it too, so we had to
develop some simple replacement classes and change Jena code to use
them (they could be used with ng4j too, with some refactoring). Note
that the latest Android API (level 8, intoduced with the 2.2 "Froyo"
release) now includes the transform API; anyway, to keep Androjena
compatible with older releases of Android, we won't rely on that
support. If you plan to use the ng4j library only on 2.2 or newer
devices, then forget about this dependency.
Jena dependencies:
- ARQ: for SPARQL queries over named graphs.
External libraries:
- bouncy castle crypto API (seems that someone already used it in
android or that android classpath includes part of the library, so
chances are that it works ootb)
- ANTLR (needed for the TriG parser, so maybe givin up that feature
could eliminate this dependency)
- Apache commons codec (needed for Base64 support, we already included
in Androjena a replacement for that, taken from Apache Xerces
implementation)
- Apache log4j and Apache commons logging (sadly ng4j uses log4j and
apache logging directly, instead of slf4j like Jena did) (because we
have ported slf4j already, see build docs)
- Apache Axis (needed for UUID generation and other web-service stuff,
maybe givin up some features of ng4j could eliminate this dependency
too)
- Apache Xerces (was used in Jena too, can be replaced with Android
parsers, at the cost of some refactoring).
- NekoHTML (which depends on Xerces too)
- God knows what more :)
As you can see, the task is all but trivial. The huge availability of
libraries is one of the coolest aspects of Java but, from an Android
perspective, is also its most painful issue, because everything relies
on everything, with Apache as a foundation. It's a matter of time
before the most important libraries will be ported; in the meantime we
hope to open the door to some mobile semantics :)
One last thing: did you try the latest androjena test application on
your HTC Magic? If not, please do it (and let it send us the results):
it would really help us figure out Androjena support over different
devices.
Bye,
lorenzo
Natanael Arndt
Jun 8, 2010, 6:17:49 AM6/8/10
to andr...@googlegroups.com
Yes, I've tried the test, but it hung at one test and I don't know, if it only sends the results after the last test or between each test. I will let it run for a longer time later, maybe this test just neads more time. I'll give you more details later.
Thank you
Natanael
Thank you
Natanael
"lencinhaus" <lore...@gmail.com> schrieb:
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
arndtn
Jun 8, 2010, 8:11:49 AM6/8/10
to androjena
The Tests are running now, if I don't need the phone until they are
ready and nobody calls me, you will get the results :-) How long do
the tests need?
On 8 Jun., 12:17, Natanael Arndt <arn...@gmail.com> wrote:
> Yes, I've tried the test, but it hung at one test and I don't know, if it only sends the results after the last test or between each test. I will let it run for a longer time later, maybe this test just neads more time. I'll give you more details later.
> Thank you
> Natanael
>
> "lencinhaus" <loreca...@gmail.com> schrieb:
ready and nobody calls me, you will get the results :-) How long do
the tests need?
On 8 Jun., 12:17, Natanael Arndt <arn...@gmail.com> wrote:
> Yes, I've tried the test, but it hung at one test and I don't know, if it only sends the results after the last test or between each test. I will let it run for a longer time later, maybe this test just neads more time. I'll give you more details later.
> Thank you
> Natanael
>
arndtn
Jun 8, 2010, 8:15:47 AM6/8/10
to androjena
The tests ended successfully:
suite: 11/18
you should have the results.
Natanael
suite: 11/18
you should have the results.
Natanael
arndtn
Jun 8, 2010, 8:16:27 AM6/8/10
to androjena
ah Status says "fatal error (java.lang.OutOfMemoryError)"
lencinhaus
Jun 8, 2010, 8:27:19 AM6/8/10
to androjena
Thanks for your patience :)
Yes, some tests take longer than the others, and the OutOfMemoryError
was expected, the important thing is the application managed to
recover from it and didn't crash as before. We received your test
results: they will be saved in a database as long as the other
received results, and soon we'll publish some statistics about device
support, performance and known bugs on the project wiki.
Thanks again,
lorenzo
Yes, some tests take longer than the others, and the OutOfMemoryError
was expected, the important thing is the application managed to
recover from it and didn't crash as before. We received your test
results: they will be saved in a database as long as the other
received results, and soon we'll publish some statistics about device
support, performance and known bugs on the project wiki.
Thanks again,
lorenzo
Reply all
Reply to author
Forward
0 new messages