Ron, (01)
We definitely need something along those lines, but there are
many options about how those functions could be supported: (02)
RW> As I wrote in an earlier posting, I wonder if there could be
> a file with a set of metadata and dependencies about the ontology
> modules that would allow the user to set up a project with a
> controlling file that identifies a set of top level third party
> modules and have the system locate the transitive dependencies
> from repositories and verify compatibility. (03)
First, I would emphasize that we have to distinguish the infinite
lattice of all possible theories from the implemented hierarchy.
The lattice is like Peano's axioms for arithmetic with all the
possible implications of those axioms. It "resides" in a kind
of Platonic heaven along with all other mathematical theories
that anyone might ever discover. (04)
The hierarchy is a finite subset of the lattice. It "contains"
all the theories that have been implemented in some version
of logic and contributed to the OOR. I put the word 'contains'
in quotes because the containment could imply actual storage
or a collection of virtual pointers. The software that supports
the repository could make the difference between actual and
virtual unnoticeable (unless somebody explicitly asked about it). (05)
The relationships among the modules in the hierarchy that were
discovered and recorded would be represented in the hierarchy.
From the point of view of any particular module, that would be
metadata, but it would be associated with the entire hierarchy,
not just with individual modules. (06)
RW> This would promote sharing and adoption of modules while
> keeping individual modules small and focused. If we can figure
> out what metadata is most helpful in determining compatibility,
> dependencies, available formats, versions, etc. that would
> allow developers of ontologies to start to work on developing
> ontologies. (07)
Yes. We need various tools and the metadata to support them. (08)
As for size, the lattice has no limit on the upper bound,
and the only limit on a lower bound is a single axiom.
The implemented hierarchy could make a distinction between
smaller modules designed for mixing and matching,
combinations of modules that were designed as convenient
packages, and huge combinations. (09)
Some of that information could be contained in metadata
about each module, which would state its provenance and how
it was derived by combining smaller modules or by dissecting
larger ones. But other information might be derived
dynamically by tools that would focus on smaller modules
or larger packages. (010)
In any case, the collection of tools will evolve as time goes on.
I would expect them to grow into an Ontology Development Platform
with multiple views and options for different purposes. (011)
John (012)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (013)
|