Hi Henry,
In general it seems that you would like to combine the entity with the
resource. For example, a Java resource receiving a GET request will
return itself to be serialized as the representation (the entity):
@rdf(atom+"Entry")
@UriTemplate("entry")
class Entry {
@HttpMethod
Entry get() {
return this;
}
}
You can do this but it does tend to merge layers. For example, JAX-RS
will need to instantiate an Entry instance to call the get() method, but
where does the Entry instance obtain the information to set it's fields?
from a database, from a file, from a triple store? does it matter? it
can do do if the layers are merged as the object is often more tightly
coupled to the source of the data.
I don't yet quite understand everything of what you say so bear with me...
> Some questions:
>
> - does one really have to have both a POJO and a Resource object?
I don't think so but the merging of layers may cause issues of where the
information is obtained and what is the life-cycle of the merged object.
> - Is there a way the id can be made to reliably work with the @UriTemplate?
I think if the instantiation of a Som(m)er class had access to the HTTP
request URI, base URI and URI path then it may be possible. A Som(m)er
class could be instantiated from the URI information specified by the
URITemplate that is obtained from runtime with additional URI
information obtained from the runtime (see UriInfo class) to ground an
instance in absolute terms.
Sub-resources can be specified by using a URITemplate annotation on a
method that returns another class from which matching continues:
class Entry {
@UriTemplate("sub")
MySubResource getMySubResource() { ... }
}
This could be the way to dynamically and polymorphically return
sub-graph (that also has sub-resources).
> - does it make sense to have a Provider that is on an <Object>
Yes, for a set of classes that conform to a classification e.g. JAXB
classes that are annotated with XmlRootElement.
I think it would be useful for us to work on a more concrete, but
simple, example starting with a set resources with URIs that return RDF
representations, that contain URIs, in response to HTTP GETs.
Then we can see the Som(m)er class and we can play with a conventional
separation approach or a merged approach for resources, see what works,
maybe see what needs to be improved in 311 and/or Som(m)er. ?
Paul.
Story Henry wrote:
> Hi, I am working on implementing an Entity Provider for RDF in Jersey.
>
> Using the so(m)mer annotations [ https://sommer.dev.java.net ] it is
> easy to map any java bean to rdf. Given that one should then be able to
> serialise any such object to any of the RDF formats. So I am looking at
> how best to do this with Jersey.
>
> A so(m)mer annotated object looks something like this:
>
>
> @rdf(atom+"Entry")
> @UriTemplate("entry")
> class Entry {
> static final String atom =
> "http://bblfish.net/work/atom-owl/2006-06-06/#";
>
> @rdf(atom+"title") String title;
> @rdf(atom+"id") URI id;
> @rdf(atom+"content") Content content;
> ...
>
> @id URI getID() { ...
> //note this is *NOT* the atom ID. a number atom entries can have the
> same atom id,
> //but only one object can have this
> //Identity. This is close to equivalent to a java object pointer.
> }
> }
>
>
> ( Usually without the @UriTemplate of course, which is a JSR311
> annotation )
>
> As the @rdf anntoations give URIs for the class names and field, so I
> was thinking JSR311 is really giving
> a way to identify *instances* of objects with URIs. This is missing in
> so(m)mer. There, if an object does not have an @id annotation and has
> just been created in Java (IE: it does not have a URI from being read on
> the net), then the object is thought to be identified by a blank node -
> its identity is local to the JVM.
>
> It could be then that JSR311 and so(m)mer complement each other well. To
> test this I decided to build a serialiser for Jersey, the reference
> implementation of JSR311. To do this I understand that I need an Entity
> Provider class, as explained by Paul Sandoz on his blog:
> http://blogs.sun.com/sandoz/entry/plugable_types_with_jax_rs
>
> Here is the beginning of my implementation
>
> /**
> *
> * @author hjs
> */
> public class RDFProvider extends AbstractTypeEntityProvider<Object> {
>
> public RDFProvider() {
> }
>
> /**
> * To start off with we support any class that has an @rdf annotation.
> * We could make this more general and support any class, full stop.
> This
> * would require having being able to create
> * a default URI for every class name and relation, and perhaps set
> up some
> * framework to publish an ontology at that URL...
> */
> public boolean supports(Class<?> type) {
> if (type.getAnnotation(rdf.class)!=null) {
> return true;
> }
> return false;
> }
>
> /** generalising this is not going to be obvious. Neet to think
> about it... */
> public Object readFrom(Class<Object> type, String mediaType,
> MultivaluedMap<String, String> httpHeaders, InputStream entityStream)
> throws IOException {
> throw new UnsupportedOperationException("Not supported yet.");
> }
>
> /**
> * this should be quite easy. Essentially we want to deserialise every
> * object in the graph starting with the given object and up to any
> object
> * that does not have a URI. (objects that have URIs will get
> deserialised
> * by fetching that URI of course)
> */
> public void writeTo(Object t, MultivaluedMap<String, Object>
> httpHeaders, OutputStream entityStream) throws IOException {
> //now how does one get the URI of an object?
> }
>
> }
>
>
>
> From looking at the code in Jersey, it looks like JSR311 is making a
> big difference between Resource objects and normal objects, so that
> there is a lot of duplication. Every object ends up requiring its own
> resource object. In som(m)er I have the @Id annotation that returns the
> URI for the object. I suppose I should have my object implement this. Is
> there a way of linking this up with the @URITemplate?
>
> The reason is that I want to serialise a graph of objects up until I
> have an object with an Id. Indeed there is no need to publish an object
> with an URL ID, since that object can be GETed itself at that id. (Ok
> One could allow more information to be sent and thereby reduce
> bandwidth consumption, by specifying that one should only go X URIs deep.)
>
> This is called a Concise Bounded Description
> http://www.w3.org/Submission/CBD/
>
> Some questions:
>
> - does one really have to have both a POJO and a Resource object?
> - Is there a way the id can be made to reliably work with the @UriTemplate?
> - does it make sense to have a Provider that is on an <Object>
>
> Hope this makes sense.
>
>
> Henry
>
> Home page: http://bblfish.net/
> Sun Blog: http://blogs.sun.com/bblfish/
> Foaf name: http://bblfish.net/people/henry/card#me
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109