Denise's comments -- (01)
--->>> I've heard both notions bandied about. Operationally, I think [an] OORx
will have both types of entities. Some organizations will want to have
or provide persistence while others may only wish to host a registry.
This is an architectural decision that will need to be made. In my mind
I think the functionality among a registry and a repository can be
partitioned in such a way that will allow plug-n-play deployment and
operation. (02)
Thanks for the reply. In one of the panel sessions there was a discussion
about the different set of requirements for actually storing versus describing
ontologies. At least two of the speakers agreed that two distinct data models
underlie storing an ontology and describing an ontology. The overlap between
thosee data models -- from my experience working with and describing ontologies
each day -- will be quite minimal. So, in our requirements for an OOR, are we
targeting the set that is common to both a repository and a registry? (03)
I will argue for a distributed non-hierarchal architecture (e.g. flat
P2P) to meet operational needs. (04)
Whether a registry is centralized or distributed is of less import to the
registry design. The underlying data model for an ontology repository, though,
cannot be restricted to a question of a hierarchical or non-hierarchical
architecture. The first design issue is which ongology components must be
accommodated in the data model, then what type of an architecture is needed to
represent each of those components. A registry can tell us what types of
components a particular ontology may have, but it may not -- without a more
explicit data model - be able to house those components. (05)
And yes, there are many additional requirements that will need to be
filled in. I was aiming for the high-level generic ones before we get
lost in the requisite details. As Leo has pointed out everything will
not be realized in the first version. Thus we need to partition the
requirements in a fashion that makes them (i.e. the high level
requirements) fairly independent. (06)
Yes, agreed. I would recommend we partition the requirements based on whether
we're simply describing the ontology or actually storing it. (07)
>
> Best regards,
> Denise
>
>
> _________________________________________________________________
> 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
>
>
> (08)
_________________________________________________________________
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 (09)
_________________________________________________________________
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 (010)
|