Perhaps things like TextAnnotation, EntityAnnotation, Category, Language, etc could have their own classes, while the domain specific stuff such as Person, Location, Sports, etc could be represented by their URIs. If the engine is returning properties alongside those URIs, perhaps a key-value structure would be as far as SINR would go? Expressive access to the RDF would still be accessible for the strong of heart, through another API.
What Fabian says still applies here, as if somebody now decides to add another enhancement that is not TextAnnotation, EntityAnnotation, Category or Language, then a new class would need to be added. I think this problem is handled in UIMA by passing JCas [1] objects around (I am no UIMA expert) I think this is where Rupert wanted JSON objects to be passed, so that no Java classes would need to be generated. Did I get it right? Another way would be to just keep it simple (for the consumer) and release new SINRs every time a new type of enhancement engine is added. Cheers, Pablo [1] http://uima.apache.org/downloads/releaseDocs/2.1.0-incubating/docs/html/tutorials_and_users_guides/tutorials_and_users_guides.html#ugr.tug.aae.defining_types On Mon, Jun 4, 2012 at 10:55 AM, Reto Bachmann-Gmür <[email protected]> wrote: > On Wed, May 9, 2012 at 8:08 PM, Fabian Christ > <[email protected]>wrote: > > > Hi Bertrand, > > > > 2012/5/9 Bertrand Delacretaz <[email protected]>: > > > On Wed, May 9, 2012 at 12:39 AM, Fabian Christ > > > <[email protected]> wrote: > > >> 2012/5/9 Bertrand Delacretaz <[email protected]>: > > >>>... > > >>> interface Category { > > >>> String getId(); > > >>> String getLabel(); > > >>> Category getParent(); > > >>> } > > >> > > >> So for each type of enhancement you would have an interface - is this > > >> the idea?... > > > > > > Yes, so that a user can say "I'd like to add Categories to this > > > content" or "I'm looking for Entities in my content", etc. > > > > I see. I am wondering how often we would have to change the API with > > this approach. The nice thing of having the data represented > > independent of the API is that we can change the data schema without > > changing the API. Now with API classes for categories, persons, etc. > > wouldn't it mean that we have to change the API if someone wants to > > add a new type of enhancement? But this would be contradicting to our > > flexible enhancement architecture where we do not know what type of > > enhancements future engines may produce. Any ideas? > > > > I think Bertrand's examples basically draft a java api for SKOS. I think > SKOS is likely to be a major usecase so it makes sense to provide > convenient APIs for accessing this. I think the naming "is not rdf" however > is a questionable marketing strategy. True is that as long as you are > accessing the data via the api you don't have to deal or know about > triples. But providing easy access at the price of expressivity doesn't > require denying the (or one possible) underlying technology. So I'd rather > focus on what it is: JSKOS, Categories4J, whatever.... > > Cheers, > Reto >
