<quote who="matthew.west@xxxxxxxxx">
> Dear Carl,
>
>>
>> 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.
>
> MW: What is the limitation of single centralized OOR? It would
> only impose a limitation on the universe of things if that was
> part of its design, and this could also be managed with a
> federated system if is was designed to achieve that. (01)
CM: Agreed (02)
>
> MW: A federated system only introduces unnecessary complication.
> If you split somethign up, you have to work out how to put it
> back together again. A federated approach should only be considered
> when things are already divided, and the question is whether it
> is cheaper to integrate by federating the existing systems, or to
> redevelop the systems as one. (03)
CM: Methinks it is the nature of the multi-ontology beast. I expect that
each ontology will be stewarded by the members of a particular
community... who will retain the right to publish it in an OOR of their
choice... with the expectation that the underlying architecture will
support a joining (aka federation) with another OOR aka federation. (04)
> MW: OK. That might be a bit strong, but a situation would have to
> be pretty hopeless before I would advocate a federated system. (05)
CM: Would you support federation as an option ? (06)
>
> Regards
>
> Matthew West
> Reference Data Architecture and Standards Manager
> Shell International Petroleum Company Limited
> Registered in England and Wales
> Registered number: 621148
> Registered office: Shell Centre, London SE1 7NA, United Kingdom
>
> Tel: +44 20 7934 4490 Mobile: +44 7796 336538
> Email: matthew.west@xxxxxxxxx
> http://www.shell.com
> http://www.matthew-west.org.uk/
>
>>
>>
>> regards
>> carl
>>
>>
>> <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 (07)
--
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 (08)
_________________________________________________________________
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/ (09)
|