Ravi, Matt, et al: (01)
IMHO The federated approach assumes that no one wants to be limited to a
single centralized OOR. The 'root' is the foundation for organization of
content within one instance of an OOR .. it does not impose a limitation
on the universe of things. (02)
regards
carl (03)
<quote who="Sharma, Ravi">
>
> Matt
>
> You raise many good points.
> Hopefully we can address them one after another.
> I am awaiting Farukh Najmi's response.
>
> For now, I will only add my professional comments to one more areas
> commented by you.
>
>
> Yes the Governance and requirements are to be included, but let them be
> simultaneous.
>
> THIS IS OPEN ONTOLOGY RSPOSITORY ARCHITECURE DISCUSSION.
>
> What I understand from Word OPEN is that it is to be decided by this
> Community that:
>
> OPEN implies:
> Open standards based
> Open access to all who can be identified or authenticated
> Open access to all members of community who want to post
> comments suggestions and opinions
> Open access to all trusted and authenticable communities (at
> least Read only)
>
> FEDERATED ARCHITECTURES ALLOW:
> Multiple authorized communities to access each other's content.
> Where Communities are closely aligned cross populate or review
> content.
> Organizations that have legitimate authorized needs can extract
> and analyze content
> - an example in information architectures will be that State level
> Justice department wants access to their or neighboring States driver
> records
> or
> - that Homeland Security or red-cross needs access to normally private
> records in healthcare situations of disasters?
>
> Thanks.
>
> Ravi
>
> (Dr. Ravi Sharma) Senior Enterprise Architect
>
> Vangent, Inc. Technology Excellence Center (TEC)
>
> 8618 Westwood Center Drive, Suite 310, Vienna VA 22182
> (o) 703-827-0638, (c) 313-204-1740 www.vangent.com
>
>
>
> -----Original Message-----
> From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
> [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of
> matthew.west@xxxxxxxxx
> Sent: Monday, February 11, 2008 4:20 AM
> To: ontology-summit@xxxxxxxxxxxxxxxx
> Subject: [ontology-summit] [Repository-Arch] Mixing Functional
> Requirementswith Physical Architecture
>
> Dear Colleagues,
>
> There is currently a proposal for a federated architecture, see my
> comments:
>
> The OOR will support a federated architecture
>
> MW: I do nto see why a federated architecture is a primary
> requirement. I can see that it might be a solution to other
> requirements.
>
> - Multiple OOR instances may belong to a federation
> - Membership of an OOR in a Federation is driven by shared interest
> - A federation typically maps to a community of interest which is
> often a vertically specialized domain (e.g. Healthcare, Ocean
> Science, Automotive, Telco etc.)
>
> MW: Well this is our first real requirement. We have communities of
> interest that might want to manage the development of an ontology
> for a domain. But why is it necessary that these should be
> implemented in a federated environment? Why is it impossible to
> implement this in a single repository that recognises separate
> ontologies under separate management?
>
> - During development Ontological content may be authored and stored
> in a local OOR instance
>
> MW: I'm not quite sure if this is supposed to mean that in the
> federation there is some central repository, or whether it means
> that for each OOR in the federation it should be possible work on a
> local copy rather than on the central repository for that OOR.
>
> MW: If you mean the latter, then this would certainly be useful,
> none of us are on-line all the time. However, most of the systems
> I know that work like this have significant performance problems
> because of the long locks that are required. Not to mention the
> problems that come from people effectively preventing write access to
> areas they are only reading rather than looking to make changes to.
> How would you intend to overcome this?
>
> - Finished Ontological content may be promoted / deployed to a shared
> community repo. This process should have human review and approval
> process
>
> MW: Why does this have to be a separate OOR? Why could it not be an
> area of a single OOR?
>
> - Changes to shared community repo are notified to interested
> subscribers (other authors)
>
> MW: The processes required to support community approval of content
> are somewhat more complex than this.
>
> - Local repos may synchronize with communtiy repo and community repo
> may synchronize with root repo periodically
>
> MW: This is the first mention of a root OOR...
>
> - Root repo will not have replica of all community repos. It will
> only have the ontological content that is common to more than one
> community.
>
> MW: It is likely to be very small then...
>
> It will also have a catalog of community repos and what
> they have to offer.
>
> MW: But this is only necessary because of the federated architecture
> you are imposing.
>
> - There will be a process to request that certain ontological content
> be promoted / deployed to root repo if it seems valuable to more than
> one community.
>
> MW: Again, this is all easier if you have a single repository in the
> first place.
>
> - There will be a broader and tighter governance process at the root
> repo and will likely have reviewers from multipel communities
>
> MW: Governance is the main issue for a Community Ontology. The purpose
> of the OOR is to hold a variety of ontologies and support the governance
>
> processes for their content. I therefore suggest that if we really want
> to be requirements driven, then we should start to look at the
> governance
> of content (since an ontology meta-model is the subject of another
> theme), rather than starting with solutions dressed as requirements
> like a federated architecture.
>
>
> Regards
>
> Matthew West
> (04)
--
Carl Mattocks
Chair OASIS Business Centric Methodology TC
co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC
ONTOLOG ONION CoP Leader
CEO CHECKMi
vmail(usa) 908 322 8715
www.CHECKMi.com
Semantically Savvy Agents (05)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2008/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2008
Community Portal: http://ontolog.cim3.net/ (06)
|