|From:||"Dennis Nicholson" <d.m.nicholson@xxxxxxxxxxxx>|
|Date:||Mon, 4 Feb 2008 11:45:27 -0000|
if they only hold one, they will need some kind of local index describing what they hold, what its features are, and how it can be accessed
(HILT, for example, is offering SRW/U access). Those running these repositories will not necessarily be directly collaborating and often won't
know about the repositories run by others. Some, like HILT, may also hold data to support cross-KOS interoperability.
- There will be a need for at least one registry that allows the various (often unknown) repositories to be found and that describes them in a
way that allows whoever or whatever (it will often be another service) is searching for them to determine whether they are useful for particular
purposes (do they cover a particular subject area, are they designed for a particular use or user, do they offer access protocols in use by the
requestor etc). Some of this data could - and probably should - be held by the repositories themselves, but there is an efficiency and
convenience case for holding the data in a central registry also
generic service registries such as IESR in the UK (http://iesr.ac.uk/) will do the job just as well or better, but, knowing how these things go, I
suppose it is inevitable that we will end up with some generic service registries including terminology repositories and some terminology
service registries as well. It is also, it seems to me, inevitable that there will be many registries and that they will 'know about' each other, but
won't individually contain information about all repostories (so that it will be necessary to find all the registries via a local one first before we
can find all the repositories)
registries. I don't fully understand the function of these yet. The JISC project I mentioned earlier is looking at this (as I understand it). For me,
these are just like federated 'repositories' according to the definition on this list and not terminology services registries. But I don't claim to
be (a) an expert on the thinking behind them (b) sure I am right in any case. It's a new area, so these things are still topics for discussion.
Again though, given the way these things go, I expect these terminology registries will also come into the architecture, and that some of them
will end up being more like terminology repositories and others more like terminology service registries.
From: oor-forum-bounces@xxxxxxxxxxxxxxxx [mailto:oor-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of dbedford@xxxxxxxxxxxxx
Sent: 04 February 2008 11:07
Thank you for contributing these ideas. I have been monitoring the discussions in background. I think it is important to start out the discussion with a context of the range of architectures that are possible (ranging from the practical/possible to the theoretical/idea). Your ideas raise a lot of questions in my mind regarding how people will contribute, communicate about, leverage and map ontologies. For a given architecture, are there a minimum set of requirements? I may have missed this point in the discussion, but have we walked through any use cases? What are the drawbacks and benefits of each architecture from a 'user' perspective (where user may be a person or an agent)?
My apologies if I am asking questions that have already been addressed and I've missed the discussion.
_________________________________________________________________ Message Archives: http://ontolog.cim3.net/forum/oor-forum/ Subscribe: mailto:oor-forum-join@xxxxxxxxxxxxxxxx Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/oor-forum/ Shared Files: http://ontolog.cim3.net/file/work/OOR/ Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository (01)
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:|
|Next by Date:|
|Previous by Thread:|
|Next by Thread:|
|Indexes:||[Date] [Thread] [Top] [All Lists]|