Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Proposed Development Approach
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  4 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Ph M  
View profile  
 More options Jul 27 2011, 12:07 pm
From: Ph M <phmart...@gmail.com>
Date: Wed, 27 Jul 2011 20:07:17 +0400
Local: Wed, Jul 27 2011 12:07 pm
Subject: Re: Proposed Development Approach

> > Request comments on the following approach to developing a Person Ontology.
> > Start by finding at least one application ... Seek additional applications
> > and build their requirements into the ontology. Repeat. ...

Here are some comments (late ones due to a registration problem).

To increase future adoption and re-use of this Person ontology,
a task before (or parallel to) the above cited ones could be to
select (re-use) Person related ontological elements from various
ontologies (CYC, MSO, ...) and align them.

If this Person ontology is well organized (via semantic relations and modules),
it will be easy for each application developer to select a portion that is
relevant for its application. From that viewpoint, no need to constrain the
size of the ontology: the more content the ontology has, the more useful it
can be, and many elements from other ontologies may be selected (re-used).

> Keep it from growing too large by adding specialized content to standard extensions.

If this Person ontology is well organized, can it become too large ?

Philippe  (www.phmartin.info)


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Jim  
View profile  
 More options Jul 27 2011, 10:13 pm
From: Jim <jim.schoeni...@gmail.com>
Date: Wed, 27 Jul 2011 19:13:48 -0700 (PDT)
Local: Wed, Jul 27 2011 10:13 pm
Subject: Re: Proposed Development Approach
Philippe,

           I used the word 'extensions' and you used 'modules.'    If
we mean about the same thing, I agree the set of modules/extensions
could grow to any size.   But shouldn't there be a core Person
Ontology, from which to extend or create modules?  If so, that's the
ontology I believe should be small enough for developers to learn in a
reasonable amount of time.

Jim Schoening

On Jul 27, 12:07 pm, Ph M <phmart...@gmail.com> wrote:


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
s...@bestweb.net  
View profile  
 More options Jul 28 2011, 6:22 am
From: s...@bestweb.net
Date: Thu, 28 Jul 2011 06:22:07 -0400 (EDT)
Local: Thurs, Jul 28 2011 6:22 am
Subject: Re: Proposed Development Approach

Philippe,
The design I have recommended many times is a lattice
of� theories.
The ones near the top are very simple, very
underspecified, and very general.� The ones beneath them can be
specialized in different ways for different purposes.
But there is
no limit on� the number of specializations that might be needed for some
purposes, but not for others.
Having too many axioms increases the
danger of contradictions.� Even when there are no contradictions, a large
monolithic ontology can slow down the reasoning engines by adding too much
irrelevant information. It is always a good idea to use the simplest
theory that is adequate for solving any particular
problem.
Performance was a major issue with Cyc, which they solved
by limiting the amount of irrelevant information that is accessible for
problems or questions that don't require it.

>> Keep it from growing too large by adding specialized content to
standard
>> extensions.

> If this Person

ontology is well organized, can it become too large ?
There is no
such thing as a perfect organization.� Every ontology is going to become a
legacy system, sooner or later.� It is always necessary to plan for future
versions, which may be very different from the current one.
John

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Ph M  
View profile  
 More options Jul 28 2011, 12:07 pm
From: Ph M <phmart...@gmail.com>
Date: Thu, 28 Jul 2011 20:07:58 +0400
Local: Thurs, Jul 28 2011 12:07 pm
Subject: Re: Proposed Development Approach
Jim> But shouldn't there be a core Person Ontology, from which to extend
Jim> or create modules?

Indeed, it is needed.

John> The design I have recommended many times is a lattice of  theories.
John> Having too many axioms increases the danger of contradictions.

It is certainly a good thing to organize modules into a lattice.
A mechanism to let people and inference engines see the whole ontology
as a unique one (and derive other modules from it, using queries) is also
important for knowledge display/browsing/comparison/cross-checking purposes.

John> Every ontology is going to become a legacy system, sooner or later.
John> It is always necessary to plan for future versions, ...

Sorry if this is not very relevant in this forum but I'd like to
note that the "whole-ontology based versioning approach" (that John seems
to refer to) may not be the only solution.
There are numerous problems associated to using versions of whole ontologies
(for dealing with ontology evolution): management of identifies accross
ontologies, implicit redundancies and inconsistencies between the versions, ...

Not using "whole-ontology versions" seem avoidable when the necessary
contexts are made explicit within the ontology, for example when
- the context (time, place, author, ...) of each belief (statement that is
  not a definition) is represented within the ontology, and
- each identifier for an object (category, statements, ...) includes an
  identifier for a context of this object (its author, its creation date,
  and sometimes some other things), e.g., as a prefix or a suffix
  (this also implies that an unprefixed/unsuffixed term is an informal term,
   not an identifier of an object with a unique meaning).

Indeed, doing so permits not to change identifiers and to
make explicit various beliefs according to people, time and place.
This may be seen either as a method to avoid file-based versioning (and its
numerous associated problems) or as a method to represent it in an explicit
way at a fine granularity instead of using file-based versioning.

For example, the following Formalized English sentence states that
on 31/12/2010, I (pm) asserted and believed that
- on 30/11/2009, in France, at least 50% of occurrences of
  what I called birds in 2009  were able to fly, and that
- this was a correction of my belief of 30/11/2009 that
  every such bird was able to fly that day in France.

pm|31/12/2010#`  `at least 50% of pm|2009#bird can be agent of a flight
                                     with place France and time 30/11/2009'
                 is a pm#correction of
                 pm|30/11/2009#`every pm|2009#fly can be agent of a flight
                                     with place France and time 30/11/2009'
              '.

This approach also permits knowledge from many sources/ontologies/modules
to be integrated in a loss-less way into a unique ontology, if only for
knowledge display/browsing/comparison/cross-checking/synthesis purposes.
This is not an argument for not also organizing modules into a lattice.

Philippe (www.phmartin.info)


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »