Dear Carl, (01)
> <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.
>
> CM: Agreed
>
>
> >
> > 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.
>
> 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. (02)
MW: No. You are talking about different people managing different content.
That is fine. It happens all the time in centralized systems. You just
have to provide the facilities for that within one system. It is not
essential for each group to have their own system (and the expense of
running their own system, and the expense of integrating that with
other peoples).
>
> > MW: OK. That might be a bit strong, but a situation would have to
> > be pretty hopeless before I would advocate a federated system.
>
> CM: Would you support federation as an option ? (03)
MW: I accept that federation is an option, just a very bad one, and
that mostly because it is more expensive, and I would have thought
we would be cost conscious in this environment. (04)
Regards (05)
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 (06)
Tel: +44 20 7934 4490 Mobile: +44 7796 336538
Email: matthew.west@xxxxxxxxx
http://www.shell.com
http://www.matthew-west.org.uk/ (07)
>
> >
> > 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
>
> --
> 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
>
> _________________________________________________________________
> 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/
>
> (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)
|