Mills Davis wrote:
> I'm encouraged by the direction of this discussion thread. Especially,
> I think that your advocacy of a lattice or hierarchy of ontologies is
> a good one if we can agree on conventions for instantiating sibling
> ontologies, ontologies that are more general, ones that more
> specialized, as well as rules for identity and provenance of versions.
> It seems that these same conventions should apply well when someone
> maps two or more ontologies together creating a knowledge fabric,
> which is a new instance that should have its own identity and provenance.
> I feel some urgency that the Ontolog community should come together on
> these issues, especially now that increasing amounts of information
> are being exposed on the web as linked data. To date most of the
> emphasis (e.g., TBL's rules for publishing linked data) has been on
> getting more data available on the web. However, linked data is not
> the same as connected data, where value can increase (beyond what
> webscale search engines are able to do already) with the density of
> relationships. For this to happen communities need policies,
> practices, and tooling to help manage and curate emerging fabrics and
> data spaces.
Methinks, Linked Data is Connected Data, that's Contextually Challenged. (02)
Yes, I agree with your broader premise: which ultimately boils down to
context, which is inherently fluid. Remember, every observer or consumer
of data does so through their own subjective context lenses :-)
> Let me give a practical near-term example. The *Open Energy
> Information* initiative sponsored by the U.S. National Renewable
> Energy Laboratory (NREL) seeks to establish a global energy
> information commons based on linked open data and data commons
> principles. The initiative has support from multiple government
> organizations, institutions, industry players in the US, north
> america, europe, etc., Its mission is to aggregate, organize, and
> provide open access to the world's information about renewable energy,
> to help catalyze and accelerate the development and transition of
> world economies to a sustainable energy future.
> Currently, NREL is wrestling with the issue of how best to approach
> data quality, and what principles, policies, practices and web-based
> tooling they should advocate and bring to the global energy
> community. Data quality and data sharing is hardly a new issue. There
> is a lot that is known, and ample literature exists dealing with
> related topics. However, what is new is the emergence of semantic web
> based approaches, the need for collaboration across diverse
> communities, and web scale information and sharing. These require some
> rethinking of policies; a new formulation of best practices for data
> management, data quality and information sharing; and some new tooling.
> My challenge to the Ontolog community is to come together to provide
> some practical guidance for how (global) communities such as this one
> can best approach the management of networked data, data fabrics, and
> data sharing. (03)
Due to subjectivity (as per comments above), assertions about data
ultimately has to take the form of annotations that end up in a give
data space. (04)
I stumble across some chunk of data on the Web (or within an Intranet),
I find it inaccurate, I make my own set of assertions about the data
item, but instead of going to war with the publisher, I deposit my
statements (which references to the original data item) in my own data
space (where the overarching world view is mine). Naturally, I publish
my data space, and the data items (or data objects) in this space have
HTTP URIs that bear an authority component associated with me etc.. (05)
When I perform queries or view data in my own data space, I can enable
my own inference context via a set of rules associated with the
underlying queries that drive my data views. Of course, someone else
could stumble across my data and choose to do so without enforcement of
my world view etc.. (06)
What I outline above is what I believe is a pragmatic mechanism for
peacefully enhancing Linked Data across public or private networks. (07)
As we all know, simply telling people: your data is wrong or its quality
is low etc., doesn't shifts happen without war, and even when war
occurs, it takes forever to be free of oversight should you seek long
term, self sustaining peace :-) (08)
President & CEO
Twitter/Identi.ca: kidehen (011)
> On Mar 3, 2010, at 9:59 AM, John F. Sowa wrote:
>> Dear Matthew, Pat, Pat, and Ali,
>> I agree with that point:
>> MW> I don't think Longman's will do much good for us, though I
>>> equally doubt it will do much harm. Frankly, I'd rather PatC
>>> got on with doing something with it so we had some evidence
>>> we could look at rather than debate a priori what the effect
>>> would be.
>> We've all seen many failures of committees to reach a consensus.
>> Furthermore, we've seen a growing number of independently
>> developed ontologies. Most of them pick and choose excerpts from
>> one another. But they never converge on a common foundation.
>> MW> There inevitably are/will be several upper/foundation ontologies.
>>> I do think there is a chance to abstract something as John says
>>> underspecified, and I do think that could be useful. This is not
>>> really what PatC is after, but it is not incompatible with his
>>> aims either...
>>> I think we need to allow multiple upper ontologies and mappings
>>> between them. Underspecified/abstract elements would be useful
>>> to make the mapping easier. They do take on different meanings
>>> when added to different ontologies, but that is fine.
>> Yes. The hierarchy of theories is designed to accept any reasonable
>> contributions of any size. It can then make all interrelationships
>> among the ontologies and subontologies explicit. By itself, the
>> hierarchy is unbiased and egalitarian. But the reviews by users and
>> domain experts can provide the guidance for making rational choices.
>> PH> The other worry I have about 'intended interpretation' is that,
>>> even when working alone, one finds that the very process of writing
>>> the formal axioms sharpens and sometimes forces one to modify ones
>>> own pre-formal intuitions.
>> Yes. And the users also modify their intuitions and intentions
>> when they see the results. Engineers have a slogan:
>> Customers never know what they want until they see what they get.
>> PC> But part of the problem is mitigated by allowing multiple different
>>> ways of representing the same entity in the FO, as long as they are
>>> logically compatible and have translations between them....
>>> The need to refine intuitions and record those distinction in
>>> logically precise form has always been part of the ontology-building
>>> process. Hard work to be sure, but not impossible.
>> That statement can serve as a good basis for collaboration.
>> AH> In fact, except for the quest to identify and create a special
>>> foundation ontology out of the primitives, what you are now
>>> proposing is indistinguishable from what is already underway via
>>> COLORE. COLORE is gathering all ontologies written using CLIF
>>> regardless of their terminology or quirks. It provides a growing
>>> platform (a repository) in which they may be inputted and relations
>>> between them explored, identified and formalized.
>> As we have agreed in other email notes, the COLORE methodology
>> is completely compatible with the hierarchy of theories. The work
>> that has already been done for COLORE is an excellent beginning.
>> But I would add some further extensions to the COLORE slides:
>> 1. The ontologies can be represented in any notation that has
>> a formal mapping to Common Logic. That includes all the
>> Semantic Web ontologies and many others. But that mapping
>> must be done before they can be admitted to the hierarchy.
>> 2. Various projects and their developers and users have different
>> preferences and requirements for notations. Therefore, any
>> ontology in the hierarchy may have multiple representations
>> for each axiom, and the tools for displaying and editing
>> ontologies can have options for highlighting or suppressing
>> some of the options.
>> 3. UML diagrams and controlled natural languages (CNLs) have also
>> been translated to Common Logic, and many users have found them
>> to be much more readable than CLIF and other notations used
>> for logic. The SUMO developers, for example, use controlled
>> English for comments that can be automatically translated to KIF.
>> Such notations should not only be supported, they should be
>> 4. Many important ontologies that could be converted to CL have
>> not yet been converted. SUMO, for example, was written in KIF,
>> which is a predecessor to CLIF. Most statements in KIF can be
>> converted to CLIF with little or no change. But a few rarely
>> used features of KIF must be checked for compatibility.
>> 5. The CycL language used for Cyc can mostly be converted to CL
>> with little or no change. But the full CycL language uses
>> metalevel features that require the IKL extensions to CL.
>> We should consider broadening the scope to include IKL.
>> 6. Some of the diagrams in those that show relationships among
>> theories can be enhanced or redrawn to show the relationships
>> to the lattice of theories.
>> 7. The limitation of OOR to just the notations currently
>> supported by Protege is untenable. OOR must support full
>> CL and even IKL. The Protege tools should be extended
>> or combined with tools that support those languages.
>> Point #7 is critical. The Semantic Web includes an important
>> collection of technologies, which must be supported. But they
>> have already moved beyond RDFS and OWL by including Horn-clause
>> logics. Furthermore, relational databases still support the
>> world economy, and the constraints and queries used for RDBs
>> are written in full first-order logic. The EXPRESS language,
>> which Matthew and others have been using, also requires full
>> FOL. And Cyc, the biggest formal ontology on earth, uses a
>> superset of FOL. The OOR *must* support these systems.
>> I am currently writing a report based on excerpts from recent
>> email notes to Ontolog Forum that elaborate these points.
>> I'll post a first draft by this weekend. Next week, we can
>> discuss further modifications and updates on Ontolog Forum,
>> and I'll post a new version of the report by March 12th.
>> After the Ontology Summit at NIST on March 16th, we can
>> discuss that report and other related issues in the session
>> scheduled from 3:45 to 5:15.
>> 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/
> 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 (013)