Dear Colleagues, (01)
There is currently a proposal for a federated architecture, see my comments: (02)
The OOR will support a federated architecture (03)
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. (04)
- 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.) (05)
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? (06)
- During development Ontological content may be authored and stored
in a local OOR instance (07)
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. (08)
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? (09)
- Finished Ontological content may be promoted / deployed to a shared
community repo. This process should have human review and approval
process (010)
MW: Why does this have to be a separate OOR? Why could it not be an
area of a single OOR? (011)
- Changes to shared community repo are notified to interested
subscribers (other authors) (012)
MW: The processes required to support community approval of content
are somewhat more complex than this. (013)
- Local repos may synchronize with communtiy repo and community repo
may synchronize with root repo periodically (014)
MW: This is the first mention of a root OOR... (015)
- 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. (016)
MW: It is likely to be very small then... (017)
It will also have a catalog of community repos and what
they have to offer. (018)
MW: But this is only necessary because of the federated architecture
you are imposing. (019)
- 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. (020)
MW: Again, this is all easier if you have a single repository in the
first place. (021)
- There will be a broader and tighter governance process at the root
repo and will likely have reviewers from multipel communities (022)
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. (023)
Regards (024)
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 (025)
Tel: +44 20 7934 4490 Mobile: +44 7796 336538
Email: matthew.west@xxxxxxxxx
http://www.shell.com
http://www.matthew-west.org.uk/ (026)
_________________________________________________________________
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/ (027)
|