- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Fri, 26 Aug 2005 10:34:51 +0200
- To: Henry Story <Henry.Story@sun.com>
- Cc: "Kirkham, Pete (UK)" <pete.kirkham@baesystems.com>, bloged <users@bloged.dev.java.net>, semanticweb@sun.com, SWIG <semantic-web@w3.org>
Hi Henry, Looks promising, the idea of leveraging Java annotations to improve the mapping is neat. One wording adjustment I'd make (on your blog): "It reduces everything to named triples..." - the triples aren't named. What I'd like to see explained more is you're squaring the circle in a couple of places: between object's set/get and RDF's kind of append-only open worldiness - e.g. what if the value you're getting doesn't have a known value in your graph? Also what about the difference in class semantics, e.g. how would you express this: X rdfs:subClassOf Y Y rdfs:subClassOf X => X owl:equivalentClass Y but *not* X owl:sameAs Y Cheers, Danny. On 8/25/05, Henry Story <Henry.Story@sun.com> wrote: > > I have posted this now on my Sun blog at: > > http://blogs.sun.com/roller/page/bblfish/ > > with some of improvements suggested by your feedback. I'll keep > working on this. > > > Henry Story > > > On 25 Aug 2005, at 11:24, Kirkham, Pete (UK) wrote: > > > > > In terms of representing intensional classes, yes. But such > > mechanisms do not easily allow extensional classes, which means you > > can't use them for classification of data, inference, etc, and so > > you can end up with a system based on the least common denominator > > of the two. > > > > > > > >> - functional: if A rel B and A rel C the A == C > >> > >> > > Typo? > > > > > > > >> Using URIs for beans is a lot better than using table names. URIs > >> are *Universal*. > >> > >> > > > > Most OO design tools have used some form of UUID for ages. Flexible > > ORM schemas use a lookup layer. > > > > A lot of what went into EJB3 is based on improving productivity for > > sort lifecycle and lifetime systems - if your business rules are > > changing weekly, you don't need an ID that will outlast the sun. > > > > > > > > > >> The above now maps very easily into UML class diagrams (which are > >> just another notation for OWL) > >> > >> > > > > Be very careful that the implementation specific semantics are the > > same. > > > > > > > > > >> In the above I have only annotated the setter method. One could also > >> > >> > > > > > > > >> annotate the getter, adder, getAll methods or even a field. > >> > >> > > > > > > > >> This ends up creating too many places for annotations > >> I think. Is there a standard solution for this? > >> > >> > > > > > > For classes, annotating the field and auto-generating the accessor > > methods is fairly standard. > > > > For interfaces, fields are static so your example probably doesn't > > mean quite what you intend it to, and has the side-effect of > > exposing superfulous static fields in the interface. > > > > I'd probably generate the interface from the OWL or from the class > > rather than trying to go the other way round. > > > > > > > >> it seems clear to me that setters and getters don't give us quite > >> > >> > > > > all that we want. It would be really nice if java beans also had > > addXXX > > > > and getAllXXX. > > > > The beans specification uses array returns for multidimensional > > values, though this is somewhat clunky. > > > > The JMI (Java Metamdata Interface) codifies a richer set of > > accessors for reflection, though it is out of data with respect to > > the UML standard it is based on, nor likely to get updated soon due > > to the fragmentation of the UML community. The eclipse EMF project > > is more current, and has some interesting modelling and code- > > generation tools, but not standardized with Sun, and based on 1.4 > > so is annotation free. > > > > > > Pete > > > > > > > -- http://dannyayers.com
Received on Friday, 26 August 2005 08:35:02 UTC