Dear Ravi, (01)
>
> 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) (02)
MW: I agree.
>
> FEDERATED ARCHITECTURES ALLOW:
> Multiple authorized communities to access each other's content. (03)
MW: Actually, this is easier with a central repository. You might need
to work quite hard to make this work in a federated architecture. (04)
> Where Communities are closely aligned cross populate or review
> content. (05)
MW: This can also be achieved more easily with a central repository. (06)
> Organizations that have legitimate authorized needs can extract
> and analyze content (07)
MW: This is also more easily done using a central repository. (08)
> - an example in information architectures will be that State level
> Justice department wants access to their or neighboring States driver
> records (09)
MW: Now I think we need a discussion on where the boundaries of an
ontology lie. For me driver records are brute facts that might be
governed by an ontology, but would not actually form part of it.
However, I am happy to admit that the exact boundary between what
people think is in the ontology space and what is in the brute fact
space is contentious. (010)
> or
> - that Homeland Security or red-cross needs access to normally private
> records in healthcare situations of disasters? (011)
MW: See above. Again I would not see healthcare records for individuals
themselves as part of an ontology, but rather governed by one. (012)
MW: I agree that organizations like these might well want to either
reference a central ontology, or even download a copy of it from time
to time, and they may wish to propose new content that they have developed
in their own systems for inclusion, but I see that as beyond the scope and
control of Ontolog. (013)
Regards (014)
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 (015)
Tel: +44 20 7934 4490 Mobile: +44 7796 336538
Email: matthew.west@xxxxxxxxx
http://www.shell.com
http://www.matthew-west.org.uk/ (016)
>
> 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
> 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/
>
>
> _________________________________________________________________
> 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/
>
>
> _________________________________________________________________
> 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/
>
> (017)
_________________________________________________________________
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/ (018)
|