Pat,
In general, while of course it's fair to have new content that is in
progress, and only partially defined, you are suggesting very substantial
additions at a high level of the ontology. The standard must be quite
different there. If someone adds a new class JoineryInvoice, and makes it
a subclass of Invoice, no harm done. You have however proposed, among
other things, adding a new concept right at the top (under the top node of
Entity), called "Context", and then a whole new tree of concepts which
include Situation, Event etc.
Now, people spend large parts of their research careers (John McCarthy,
Guha etc) working on context logic. There are yearly conferences on the
topic. Context usually involves a context logic that is not first
order. And yet, you've inserted this notion without definition. In
addition, since the first level concepts of Physical and Abstract already
form a partition (are exhaustive), it's not even clear in the most basic
sense what "Context" means, nor how it would be used in inference, that in
most prior research has involved speculative reasoning facilities that
don't even exist yet.
From there the problem just gets worse since you seem to be proposing a
whole new scheme for representing situations for SUMO. Again, this is an
area that has received a vast amount of research effort, and you've
provided only a taxonomy. New content at this level simply has to be
justified with axioms even to be a coherent proposal. Otherwise we don't
have any basis for a coherent discussion about its merits. (01)
Adam (02)
At 12:56 AM 2/21/2004 -0500, Patrick Cassidy wrote:
>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.
>
> As to the specific issue you mentioned:
>
>[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.
>
>[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".
>
> 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.
>
>[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.
>
> 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.
>
> 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.
>
> 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.
>
> Should we have a vote on the question?
>
> Pat
>
>=================================
>
>
>Let me give one example where
>we can avoid extra work this way: we may want to specify that
>the
>
>
>
>
>
> "FieldOfStudy", "Procedure" and "Argument"
>"Agreement"
>
>
> 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
>
>Adam Pease wrote:
>
>>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
>
>--
>=============================================
>Patrick Cassidy
>
>MICRA, Inc. || (908) 561-3416
>735 Belvidere Ave. || (908) 668-5252 (if no answer)
>Plainfield, NJ 07062-2054 || (908) 668-5904 (fax)
>
>internet: cassidy@xxxxxxxxx
>=============================================
>
>_________________________________________________________________
>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 (03)
_________________________________________________________________
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 (04)
|