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


Help: OASIS Mailing Lists Help | MarkMail Help

ihc message

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

Subject: [FWD: RE: [regrep] Wiki + ebXML Registry + REST technology]

Here's the "mini-spec" for the semantic registry approach with wiki + ebxml registry that I sent to Farrukh + regrep.
I also found this large list after your helpful hints on today's call:
Could there be one's here we would want to short list for possible test driving this approach?
(Assuming they are OSS license compatible of course!)
Thanks, DW

"The way to be is to do" - Confucius (551-472 B.C.)

-------- Original Message --------
Subject: RE: [regrep] Wiki + ebXML Registry + REST technology
From: "David RR Webber (XML)" <david@drrw.info>
Date: Wed, February 28, 2007 6:05 pm
To: "Farrukh S. Najmi" <farrukh@wellfleetsoftware.com>
Cc: "regrep@lists.oasis-open.org" <regrep@lists.oasis-open.org>

Here's the thumb sketch on a sample use case.
Wiki users need to provide richer content capture -  but we want to do that from inside the wiki interface.
Example would be - a medical focused wiki - team is developing understanding of a research area.  They create typical wiki content around their actual research - but now realize they need to classify and formalize a vocabulary and relationships (associations) between the core concepts and medical entities.
Create some wiki template pages for registry a) classification entry b) concept c) association.
Each of these under the hood would be putting content in the registry using the users wiki profile.  If it's there already then it does 'update', else 'add' - idea is to make interface model as simple as wiki already.  Optionally can insert XML formatted content extracted from the wiki page entry items.
Wiki would store return result + unique Wiki-item-ID# (returned by registry) - this would allow simple referencing to this - and a simple "My concept items" list on the Wiki interface.  These then work via "smart linking" - if user clicks on one of these Wiki-item-ID# - then query goes to registry on external-id to retrieve content.
Create query services for registry to return HTML pages of a), b) and c) returned from registry given search token. Add these search links to each of a), b) and c) - so users can see what is there already as they are adding new ones.  
A fourth wiki template page d) would be a Submit Resource Item - that allowed uploading of document - PDF, Word, PPT, XML - directly as contribution.  This could be standalone (e.g. - just gets added to registry with generic classification ) or in tandem with b) as an option link.
This would then be an ebXML Registry "plug-in" for the wiki. 
Adminstrators could obviously use the regular registry UI to correct or enhance basic content from the wiki entry.
Obviously we could then eat our own dog-food here - to enhance the current registry wiki!? ; -)

"The way to be is to do" - Confucius (551-472 B.C.)

-------- Original Message --------
Subject: Re: [regrep] Wiki + ebXML Registry + REST technology
From: "Farrukh S. Najmi" <farrukh@wellfleetsoftware.com>
Date: Wed, February 28, 2007 5:21 pm
To: "David RR Webber (XML)" <david@drrw.info>
Cc: "regrep@lists.oasis-open.org" <regrep@lists.oasis-open.org>

Thanks for pointing this subtlety out. I am still a little unclear on
what you envision.
Perhaps a crisp use case scenario or two might get me to understand better?

Thanks in advance.

David RR Webber (XML) wrote:
> Farrukh,
> The point is not that registry is backend store for wiki - I realized
> early back two+ years ago - that wiki already has all the archiving
> and storage it needs + management control features and web content
> metaphor (HTML) - and that basic use case of storage medium is not enough.
> Back to 2007 - Wiki clearly is the new "Google / MySpace / Skype"
> buzzword - and so there's a scramble on to deliver enhanced Wiki
> solutions.
> Wiki = collaboration tools via web with minimum intrusive authoring
> controls.
> Now - once people have mined out that bucket - the next level is more
> formal information management...
> It's only a matter of time before the need to have a seamless
> integration between the wiki front end - and a more capable
> semantically enabled rich content system - with policy controls - aka
> - registry - occurs - especially for complex content such as medical
> research and geospatial data.
> Even getting a simple demo system up and running right now could be
> highly beneficial... with some simple content sharing enabled to the
> wiki from the registry system - would be my assessment.
> DW
> "The way to be is to do" - Confucius (551-472 B.C.)
>     -------- Original Message --------
>     Subject: Re: [regrep] Wiki + ebXML Registry + REST technology
>     From: "Farrukh S. Najmi" <farrukh@wellfleetsoftware.com>
>     Date: Wed, February 28, 2007 3:51 pm
>     To: "David RR Webber (XML)" <david@drrw.info>
>     Cc: "regrep@lists.oasis-open.org" <regrep@lists.oasis-open.org>
>     +1 on this terrific idea!
>     Now why didn't I think of that.
>     Wait. I think I did ;-)
>     See:
>     <http://ebxmlrr.sourceforge.net/wiki/Overview#Collaborative_Authoring:_An_Illustrative_Use_Case>
>     This cool idea is still on my TODO list.
>     David RR Webber (XML) wrote:
>     > Team,
>     >
>     > I attended the NIH wiki fair today - and wiki is a hot collaborative
>     > technology for government with numerous uses from the CIA across to
>     > the HHS and thru to GSA agencies.  GSA offers wiki hosting
>     services to
>     > all agencies.
>     >
>     > What it is of course is a familiar and simple user interface
>     > experience that works for people with a minimum of web authoring
>     > experience - who need to collaborate to develop a common human
>     > readable understanding of domains and topics.
>     >
>     > There is a strong opportunity for ebXML Registry to leverage this
>     > however - by linking formal, machine and ad hoc mechanisms for
>     > information and knowledge management .  
>     > What this means is that Wiki is potentially a great simple UI for
>     > registry - via both a default access profile, and then specific user
>     > login profiles.
>     >  
>     > In Wiki you can create "New Page" templates that conform to registry
>     > entry patterns - and then "Save/Update" will persist to both the
>     Wiki
>     > and the Registry.  The entry pattern would provide classification
>     > choices and can return unique "information anchor IDs" for the
>     Wiki.
>     >  
>     > Equally - Wiki only provides static page links - while using a REST
>     > link to Registry can return dynamic query results.  So users can
>     embed
>     > dynamic content into their Wiki entries.
>     >  
>     > And then classifications of course can be managed by registry - with
>     > links over to registry proper to allow that navigation mode.
>     >  
>     > Machine interfacing can then be done to return formal results
>     from the
>     > registry that correspond to entries in the wiki.
>     >  
>     > This is something that I'm seeing will be part of the solution
>     mix for
>     > us by the end of 2007 here.
>     >  
>     > DW
>     >  
>     > "The way to be is to do" - Confucius (551-472 B.C.)
>     --
>     Regards,
>     Farrukh
>     Web: http://www.wellfleetsoftware.com


Web: http://www.wellfleetsoftware.com

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