OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [xtm-wg] User API - A new endeavour for topicmaps.org?


Hello,
I strongly support that suggestion of having standard API for TM navigation,
query and editing.

This will allow faster development from the TM community based on any engine
they wish to use.

A lot of us have been working on API and it might be the time to make a
minimum set of common basic API for the developer community.

Sincerely

Jean Delahousse
CEO Mondeca
Mobile : +33(0)6 16 90 73 95
Tel : +33(0)1 47 46 18 89
Fax : +33(0)1 47 46 01 09
www.mondeca.com

> -----Message d'origine-----
> De : Thomas B. Passin [mailto:tpassin@home.com]
> Envoyé : vendredi 8 juin 2001 19:04
> À : xtm-wg@yahoogroups.com
> Objet : [xtm-wg] User API - A new endeavour for topicmaps.org?
>
>
> Now that there seems to be agreement to leave syntax and essential model
> development to the ISO work, there is the question of what work should be
> done under the aegis of OASIS or whatever, not that there is any lack of
> possibilities.
>
> I'd like to suggest that there is one area that urgently needs
> attention and
> would be a perfect match.  It's a Topic Map API for user
> programs.  By this
> designation, I mean to distinguish it from an inteface for building and
> maintaining a topic map.
>
> Such an API should be as uncommitted as possible to the
> underlying model, so
> that it would work with multiple implementations.  For example,
> the user API
> shouldn't have to know whether the underlying engine uses a graph or a
> containment model.  After all, the user at a browser (or whatever) won't
> know or care.
>
> Right now, all demo (and more serious) programs have their own
> code to talk
> to their own engines.  A good API would allow for developmer to
> concentrate
> on the larger issues, such as how the user should interact with
> the system.
>
> A user API would be based on likely user scenarios or use cases.  Some
> things seem pretty obvious.  For example, users will want to see lists of
> topics, scopes, and associations in some way, but mostly by name.
>  They will
> want to get information of a topic having selected it by name,
> and will want
> to apply filters that, again, would be selected by name.  Perhaps the API
> would even let a user create a topic and add it to the map.
>
> A user API would presumably eventually support requests for inferencing
> based on the nature of associations.
>
> Perhaps, topicmaps.org/OASIS could even build a reference implementation
> based on the API.  That would be extremely valuable.
>
> I have been working on an API myself, mainly because I want to play with
> scopes, selecting, and filtering and will need some way to access the map
> data.  I'd be happy to contribute this rudimentary effort if it
> might act as
> a seed for more work.
>
> Thoughts and suggestions, anyone?
>
> Regards,
>
> Tom P
>
>
> To Post a message, send it to:   xtm-wg@eGroups.com
>
> To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>


To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC