Empire ?

[uoccou]

Have you looked at Empire yet ? Any opinions ?

http://github.com/clarkparsia/Empire
http://www.semanticuniverse.com/articles-empire-where-rdf-sparql-meet-java-persistence-api.html

[Taylor Cowan]

I saw Kendall announce it on Twitter. I have only good opinions...but
I've not used it. JPA like this is a good idea for teams already
familiar with it, however, just as the article states...JPA is fairly
RDBMS biased so some of it's features do not/nor should never be
mapped to RDF.

@Namespaces({"frbr", "http://vocab.org/frbr/core#"})
@Entity
@RdfsClass("frbr:Expression")

I like how the @Namespace is mapped to a prefix that can be used
elsewhere...that's a good idea.
I think Jena support comes through the sesame 2 jena bindings.
Give it a try and let us know how it goes.

Taylor

> --
> You received this message because you are subscribed to the Google Groups "jenabean-dev" group.
> To post to this group, send email to jenabe...@googlegroups.com.
> To unsubscribe from this group, send email to jenabean-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/jenabean-dev?hl=en.
>
>

[uoccou]

Isn't JPA in the same vein as JenaBean - make a data technology more
object programmer friendly ? That may be taking the abstraction too far :-)

I've seen the JPA example code in JenaBean - are you planning on
progressing it ?

Its an attractive proposition to anyone in the enterprise data world -
they get to experiment behind the interface. Try out semantic
repository, see if theres a benefit in SPARQL, inference etc, and if it
doesnt work, switch back to a JPA implementation with a traditional
RDBMS. So, its to be encouraged I think.

[Taylor Cowan]

Yes, there is a JPA provider in JenaBean with some minimal
functionality. It does add
to the dependencies...it uses javasist to wrap the beans an runtime
so that there can be only one instance in the EntityManager per
individual...but the javasist makes lazy loading and other aspects
easier.

Here's an example:
http://is.gd/cOkAM

One area where JenaBean JPA diverges is in the configuration...instead
of the JPA standard XML, Jenabean's configuration comes from a Jena
assembler as turtle. Here is the test assembler:

http://code.google.com/p/jenabean/source/browse/trunk/jpa/src/test/resources/testassembler.n3?r=775

So when you create the entity model, you give it a shortened URI that
points to the model:

EntityManagerFactory emf = Persistence
.createEntityManagerFactory("tws:filemodel");

Henceforth "emf" is reading from /updating the model created within
the assembler.