[Top] [All Lists]

Re: [ontology-summit] [Repository-Arch] Mixing Functional Requirementswi

To: "Ontology Summit 2008" <ontology-summit@xxxxxxxxxxxxxxxx>
Cc: carlmattocks@xxxxxxxxx
From: "Carl Mattocks" <carlmattocks@xxxxxxxxxxx>
Date: Mon, 11 Feb 2008 14:31:08 -0500 (EST)
Message-id: <50915.>

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)

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.
> 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)
>       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
vmail(usa) 908 322 8715
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)
<Prev in Thread] Current Thread [Next in Thread>