Sorry to take some time to respond. There have been a few holidays
around here and I got involved learning about security and identity
on the semantic web...
On 8 Aug 2007, at 12:22, Paul Sandoz wrote:
> 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;
> }
> }
Ah yes. Good way of looking at it.
> 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?
I was think that this would depend on how the server wanted to set
things up, and may I suppose change in many different ways. For
example the @rdf annotations could be placed
- on a Hibernate bean which is linked to a normal database, as in
the Bookmark example
- on a POJO which via a so(m)mer is linked to
+ an rdf database
+ a virtual database hiding an sql database (mapped via d2rq for
example)
+ an rdf file
+ an xml file that gets GRDDLed to rdf
But I can see that there is a layer needed to create the mapping...
Now I am wondering is if one needs to create one Resource per class
that is made visible. If I were to create a read only web site, could
I not have ResourceGroup that given a URI requested could decide
whether the object existed or not in the database? In so(m)mer I
could have something like this, assuming the database knew of the
correct local URLs already:
mapper.getObjectById(uri,clazz);
This would require just the knowledge of which class to look for at
which URI.
In the case of the mapping to Hibernate, I suppose the URI contains
enough information to deduce both the class and the primary key of
the object being looked for.
<reading what="the spec"/>
So I think I now see how JSR311 thinks about things. You have a root
class that has a hard coded map to a root resource. From then on by
walking through @UriTemplate methods one ends up constructing a path
to the object to be displayed. I suppose this could be quite deep.
In the case of the Bookmark Example, only the UsersResource class has
a @UriTemplate annotation. The others are reached via @UriTemplate
resource methods.
Is it possible to avoid going through all the intermediate object
creations stages, such as when one is walking through a simple
directory structure? ... <thinking/> I suppose that this is done
using the UriInfo class on a ResourceMethod... That would be a way to
create a very generic structure for creating objects, if one wanted
to avoid creating to many classes...
<thought>
The Resource objects are really navigation objects. In Web
Architecture the resource is the object that the URL is pointing to.
This has to be the POJO that is returned by the get() method. What is
called a Resource object is really a resource manipulation/navigation
object.
</thought>
> 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.
I'll try thinking of the Resource as a navigation object, and see
how far that gets me.
>
>> - 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.
Thanks, that was helpful. Still need to try it out to see if I have
correctly understood.
> 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).
ok.
>
>> - 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. ?
Ok. I'll do that this week.
Thanks for the feedback.
Henry
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net