Adam -
Thanks for your comment. Since the issues you discuss
are relevant to much of the work we will be doing, I am
sending this reply to the whole Ontolog group. The bottom
line of this message is that I think we need to vote
on the issue, so I hope all Ontolog members will
slog through this and provide their own feedback.
The first point that I think needs to be mentioned is that
in adding content to an ontology I find it very useful to
create a framework of related classes which have not been
fully defined, so that the general outline of some set of concepts
surrounding a central concept at issue is clear, before
all the relevant detail for all the classes and relations have
been added in, and there is a general sense of what needs to
be done as a guide to doing it. Since almost very concept is
related to many others by a small number of links, it is
very difficult for me to focus on writing all specifications for
one concept before adding any others.
As a result, as you noticed, a subclass may be added
at first without any distinguishing features to differentiate
it from the parent, unless it has subclasses, which, of course,
are distinguishing features. Although the comments will
indicate what is intended and therefore what will have to be
added to make the logical structure match the intended structure.
What this means is that parts of the ontology being worked on
at any given point will be incomplete, a work in progress, rather
than a finished product. This is true of every ontology I have
looked at, including SUMO. I don't fault others for having only
comments to distinguish subclasses from the parents, because
I understand that at any given time, sections will be at an
intermediate stage on the path toward a definition sufficiently
detailed for practical use. (01)
As to the specific issue you mentioned: (02)
[AP]
> For example, you've created a new type of Communication, but haven't
> supplied axioms that describe how it is different from its parent.
>
"Communication" differs from its parent "AbstractInformationalEntity"
in that it has two relations, "hasIntendedAudience" and
"hasAuthors" , which are not present as relations on the parent.
These relations are immediately evident in the Protege SMINK007
class display window for "Communication": at the top of the list
of Template Slots in the "Template Slots" pane, those two relations
have a light blue "S" box to their left, indicating that they are
attached directly to that class, rather than inherited, as are
the other slots in that pane, with a white "S" box to their left. (03)
[AP]
> The comment is also misleading since you haven't defined Assertion as a
> Proposition, and in fact couldn't do so, since Communication is Physical
> which is disjoint from Proposition, which is Abstract.
"Communication" in SMINK007, like its parent
"AbstractInformationalEntity", is abstract. If you enter
"Communication" in the Protege SMINK007 class search box,
the hierarchy will open up to show the hierarchy path
directly back to "abstract". (04)
What has doubtless caused some confusion is that the class
"Communication" in SMINK007 is not the same as the class
"Communication" in SUMO -- the name for the SUMO process of
communicating has been renamed to "Communicating".
In the KIF file "samin007.txt" where Communication is defined
by a "subclass" statement you should also see the proposition:
(relatedInternalConcept Communication Communicating),
which was included in an (apparently unsuccessful) attempt to warn
the user that there is a distinction between these concepts.
In general I refrained from renaming SUMO concepts, precisely
to avoid confusion among those familiar with SUMO, but in a
handful of cases it appeared desirable to change concept names
to avoid misleading term names where distinctions among
closely related concepts needed to be made. "Communication"
was one of the few cases of renaming. (05)
[AP]
> My suggestion would be to start over, using the existing facilities of SUMO
> and MILO, and just focus on the practical representational issues
> involved in orders and invoices. (06)
The class "Communication" and one of its descendants "AbstractInvoice"
were added precisely to focus on the issues involved in representing
Invoices and its components and related documents, but the approach I feel
would be most productive is to represent these concepts not as physical objects,
but as abstract conceptual entities. The conceptual entities constitute
the propositional content of the physical documents, and I believe that it
will be much easier to visualize relations among the Invoice-related
documents and their component texts by focusing on the propositional
content rather than the physical documents. Your suggestion was to
include "Invoice" as a type of ContentBearingObject, which is a
physical object. That's fine, such things exist. But a physical
Invoice may take the form of a piece of paper, magnetic fields on a disk,
holes in a CD, light pulses on a monitor, or a variety of other forms.
In deciding what are the relations among documents and their
components, it seems likely to me that we will be concerned with
issues of information content that have nothing at all to do with the
physical form of the representation of the content. Therefore I believe
that the Ontolog group should first concern itself with the relations
among the information entities, and avoid as much as possible any
need to deal with questions of physical representation. When it becomes
necessary to deal with physical representations of Invoices or their
components, each conceptual entity would be related to the physical
object which embodies it by the relation "isAbstractContentOf" --
domain 1 is AbstractInformationalEntity and domain 2 is the SUMO
"ContentBearingObject".
You may feel that having an abstract set of concepts parallel to
the physical documents that represent them is redundant, but
I believe that in thinking and communicating about documents and
their parts, people most often (not invariably) are concerned
with the informational content rather than the physical representation,
and the relations among the informational entities are those of
greatest concern to the Ontolog group. For example, in dealing with
the concept of a Currency Code, I want to specify that a Code is
an element of a CodeList, and that a CodeList is a List. But
List is abstract. Now, of course, we could define a PhysicalList
as the physical representation of a Code List and specify
relations among the physical objects. But I also want to
specify that CodeList is maintained by a StandardsAuthority.
Of course, what is maintained is not the individual physical
items that represent a CodeList -- individuals may make and
alter those freely -- but the conceptual content of the
CodeList. So now we would need to use a function that
extracts the conceptual content of a ContentBearingObject and
relate the return value to other entities that it may be related to.
When we want to specify a specific instance of a CodeList, if we
use the physical objects, we will have to point to a piece
of paper, or a computer file, or whatever. The propositions
we write about an instance of CodeList (or invoice) will
be relations on physical objects, and will not by themselves
apply to relations among other instances of the same conceptual
CodeList. (07)
We can do it that way; I suspect that anything that can be done
relating propositional contents can be expressed ultimately as
relations among physical entities, given the proper functions.
But it strikes me as clumsy, non-intuitive, and unnecessarily
complicated.
Perhaps it is a matter of taste? I think the relations are
clearer when dealing with the conceptual entities, but perhaps
others may prefer to think about documents and their components
as physical things. So this is an issue that really needs to be
decided by the Ontolog group as a whole. What are we most
comfortable with? Do we want to worry about what happens
to an invoice we are looking at on a monitor, when we shift
to a different window? Does it still exist? At this
point, is there any reason why we should concern ourselves with such
questions? I do hope we decide to focus on the propositional
content for now. (08)
I think that this is very basic issue and that we need to
resolve it before proceeding further with the formalization.
Since Adam has rejected the content that I have suggested (though
I am happy to accept anything he thinks is useful as long
as it is logically consistent with what else is in the
ontology), it seems that I may be wasting time to continue
until this issue is resolved. I can work with any representation,
but I feel it will be easier to work with the conceptual
content of invoices and related documents. (09)
Should we have a vote on the question? (010)
Pat (011)
================================= (012)
Let me give one example where
we can avoid extra work this way: we may want to specify that
the (013)
"FieldOfStudy", "Procedure" and "Argument"
"Agreement" (014)
The Class "AbstractInformationEntity" was added to provide
a way to represent information objects, especially text objects,
that may take numerous physical forms, but focusing on the
textual content rather than the abstract propositional (015)
Adam Pease wrote: (016)
> Pat,
> You've obviously put a lot of time and effort into your file of new
> content, so I don't want to keep being discouraging, but there are a lot
> of problems. As a general comment, I think if you stick to trying to
> represent directly the information in orders and invoices your efforts
> will be much closer to what's needed. It's tempting to think there
> might be problems and gaps in SUMO and MILO that need fixing, but in
> general, what you have done is to create a great deal of content that is
> either undefined, or redundant or both. I find that in general when
> people say that some new high level content is needed, it's simply
> because they haven't yet understood the content that's already there.
> For example, you've created a new type of Communication, but haven't
> supplied axioms that describe how it is different from its parent.
>
> (subclass Assertion Communication)
> (documentation Assertion "An Assertion is a Proposition which describes
> a state of affairs and asserts that the state holds. It may have the
> value of true or false. Assertions usually are simple, describing one
> fact, but may be more complex, i.e. may be composed of multiple
> assertions. An Assertion is a communication from one IntelligentAgent
> to another.")
>
> The comment is also misleading since you haven't defined Assertion as a
> Proposition, and in fact couldn't do so, since Communication is Physical
> which is disjoint from Proposition, which is Abstract. So you've not
> only created something that is not useful for inference, since it hasn't
> been defined, but also that if it were defined as stated in the comment,
> would yield a logical contradiction.
>
> A result of creating this class is that you've created another
> semi-redundant relation of hasModalAttribute because Assertion doesn't
> fit the argument type restrictions of modalObligation, as you note. So
> now that results in a whole other redundant (and contradictory) way of
> expression model information.
>
> This is just the start of the list of comments I could make, but I don't
> think it would be a good use of our time to go through them all. My
> suggestion would be to start over, using the existing facilities of SUMO
> and MILO, and just focus on the practical representational issues
> involved in orders and invoices. I think if you start small, maybe with
> the one term I suggested you define in my email of 1/16, we could talk
> about your definition, and probably make more rapid progress on the
> representation. Focus on small, correct additions to the ontology. If
> you take things a step at a time, I'd be glad to help.
>
> Adam
>
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Subscribe/Unsubscribe/Config:
> http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/ To Post:
> mailto:ontolog-forum@xxxxxxxxxxxxxxxx
>
> (017)
--
=============================================
Patrick Cassidy (018)
MICRA, Inc. || (908) 561-3416
735 Belvidere Ave. || (908) 668-5252 (if no answer)
Plainfield, NJ 07062-2054 || (908) 668-5904 (fax) (019)
internet: cassidy@xxxxxxxxx
============================================= (020)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Unsubscribe/Config:
http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (021)
|