Re: java annotations & the semantic web

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