John F. Sowa wrote:
> We definitely need something along those lines, but there are
> many options about how those functions could be supported:
> 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.
> 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.Th
I am not sure how far this is away from the concept of java libraries.
There is an infinite number of possible libraries and a very large
number of implemented libraries. Some duplicate the same namespaces with
different module names. Some provide variations of the same
functionality with ommissions and extension under different names.
> 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).
This is the function of the Maven POM files in a Java environment. They
allow a programmer to declare that there code is dependent on a set of
libraries. It does not care about namespaces (packages). It only is
concerned with identifying and locating libraries.
> 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.
Maven can read POM files and locate dependencies and transitive
dependencies in the repositories that Maven is told about.
Each POM file is a starting point and description of its own hierarchy
so that you can identify a dependency on a sub-hierarchy without having
to specify any level lower than the direct dependency.
If a similar system existed for Ontologies, I would hope that I could
specify that I needed a certain polymer library and have the polymer
library tell my ontology engine what dependencies that it has without me
having to do that.
Maven allows me to explicitly exclude dependencies in case I have a
better (usually later) version of a library coming in through another
hierarchy. I am responsible for knowing that this will work.
In my polymer example, I may want to exclude its plastic sub-library
since I have a better one that is fully compatible but has more company
specific information included. (01)
Maven does allow the higher level POM files to manage dependencies of
lower level POMs but this is used rarely and costs you a bit of the
independence that you get with transitive dependencies. (02)
In an ontology system, if it is possible to restrict the scope of each
chunk of metadata to its own information and that of its direct
dependencies, it will be easier to have different groups building each
element in the hierarchy.
> 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.
> Yes. We need various tools and the metadata to support them.
> 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.
I am not sure how hard this is to conceptualize. In the Maven world, you
can build very small projects and immense applications with the same POM
language. The ability to express the hierarchy through a hierarchy of
POM files is very powerful.
The ability to specify a list of repositories once, that you want
searched automatically saves a lot of trouble.
Combining Maven with a Repository server that proxies the foreign
repositories and contains your own artifacts is also a powerful tool. (03)
> 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.
Exactly. Just keep it simple and transitive so that it is easy to build
and use. Application designers do not want to know the whole tree, only
the part that they directly reference. The less that one has to know
about the lower levels, the easier it is to get applications built.
In my Java programs, I do not care what libraries are used to establish
an Internet connection. I just want an HTTP connector that can get a
message moved. I want the person who wrote the HTTPConnector class that
I call, to have specified in his POM file for the HTTPConnector library,
all the dependent libraries that are required to use the methods that I
I do not want to have to find them through a string of ClassNotFound
Exceptions followed by Google searches for possible jar files. (04)
It would be nice if the ontology metadata could do the same thing. (05)
> 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.
I would urge the group to put some thought into the metadata and the
ways that it could be expressed in a OOM Ontology Object Model. (06)
> 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
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
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 (09)