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
