Pat,
I really appreciate all the work you are doing. I still have concerns
about some of the choices in representation you are making, which I'll try
to address in the next two days, but I'm sure we can work it out. Many thanks. (01)
Adam (02)
At 04:47 AM 7/13/2003 -0400, Patrick Cassidy wrote:
>MDaconta@xxxxxxx wrote:
>>Hi All,
>>Ok, here is an initial whack at an Invoice ontology.
>>See http://www.daconta.net/UBLOntology.html.
>
> In response to Mike Daconta’s effort to make concrete
>progress by creating a Protégé ubl ontology:
> To illustrate further the comments I made about how invoices
>and parts of invoices could be represented as abstract objects, I
>have taken Mike Daconta’s modified version of SUMO and
>made a few changes and additions which use the notion of
>abstract texts and the relation of abstract texts to the physical
>texts that represent them.,
>
> The modified Protégé files are available at:
> ftp://micra.com/ontolog/ubl-invoice-V0_11.pins
> ftp://micra.com/ontolog/ubl-invoice-V0_11.pont
> ftp://micra.com/ontolog/ubl-invoice-V0_11.pprj
>
> The intended meanings of the classes I added will be found in the
>documentation frame of the class window for each such class
>in the Protégé version.
>
>************
> IF you think this line is worth pursuing, please suggest
>what you think should be different. I will then try to
>add more detail along with whatever structures others contribute
>to the ontology. Feel free to ask questions to me directly
>via email or via the list.
>************
>
> As Adam pointed out, it is not absolutely necessary to create
>classes of abstract referents for each physical document that
>might be encountered in the world, as I am doing here. One could,
>as in SUMO, have functions that take as arguments the physical object
>and return the abstract object that the physical object represents.
>One could use such functions for reasoning about the abstract
>objects. However, for representing relations among the abstract
>objects, such as the fact that a “TaxAmount” is part of an Invoice,
>and is also a subclass of “CurrencyMeasure”, it can be convenient
>to work directly with classes of the abstract objects themselves.
> It will be difficult to make an objective evaluation of such
>different representation choices with out a working application
>that can use the ontology. Lacking that, we can only do “thought
>experiments” to try to visualize how a program might reason with
>different concepts represented in different ways. I prefer to
>include all of the reasonable concepts that might be useful, as
>long as they are not logically contradictory to each other.
>
>
>*************************
>Questions about two items in Mike’s V0.1 ontology:
> “Percent” (range restricted to 0 to 100): is it possible to have e.g.
>“a 300% increase in profits in the first year”?
>
>“Sending” and “Receiving”: are these intended to be the beginning and ending
>phases of a “Transportation”? If one or both are intended to include
>all phases of the shipping process, then it might be properly
>placed under “Transportation”.
>
>**********************************
>
>The specific changes to Mike’s version 0.1 ontology added
>to version 0.11 were:
>=========================
>(1) Under “Abstract” I have added the classes:
>
>AbstractSymbol
>Text-Abstract
>AbstractGraphicalObject
>
>Text-Abstract was created as the most general “Proposition” that was
>in textual form. “Invoice” is moved to become a subclass.
>AbstractSymbol and AbstractGraphicalObject were added to clarify the
>intended meaning of “Text-Abstract” and to show some of the
>abstract ideas that are not abstract texts.
>
>
>(2) I also created a new relation “representedBy” to relate such
>abstract objects to the physical objects (ink on a page, electrons
>in a computer memory) that represent these abstract objects
>in a form that people create for other people to access. For these
>specific abstract entities, they are all created by intelligent agents and
>the representations are created by intelligent agents. I have
>not yet added the relations to intelligent agents, but will do so
>if this group thinks it desirable.
>
>The relations of these general categories of abstract object
>would then be:
>
>AbstractSymbol representedBy ContentBearingObject
>Text-Abstract representedBy Text
>AbstractGraphicalObject representedBy PictorialObject
>
> ** and the inverses **
>PictorialObject containsInformation AbstractGraphicalObject
>Text containsInformation Text-Abstract
>ContentBearingObject containsInformation (AbstractSymbol
> Proposition AbstractGraphicalObject)
> [i.e. a ContentBearingObject may contain information
> from one or more of those three categories].
>
>[[“Abstract” could also have a subclass of abstract sound sequences which are
>not propositions e.g. “AbstractAudioObject”, such as Beethoven’s Ninth
>(which may
>have numerous physical representations, as the sound sequence itself
>(sound waves in air)
>or as recordings, or as a symbol sequence, e.g. a score or a symbol
>sequence for a midi player). I didn’t add this to the ontology at this
>point.]]
>==================
>
>(3) Product I changed this to “ProductObject” because services are often
>considered
>as Products of service companies. This terminology avoids confusion.
>
>(4) Under “Process” I added “CommercialService” which is a process or event
>provided by a vendor to a customer for a fee. Some instance of this
>may show up as an item on an invoice. Shipping, for example, is a
>service. I have not made the class “Shipping” (which Mike added) as a
>subclass of this “CommercialService” because some shipping may be
>done privately, for one’s own purposes. If we had a subclass of shipping ,
> e.g. “ShippingService”, then this would also be a subclass of
> “CommercialService”.
>
>
>==============
>(5) Invoice etc:
>“Class” would not be the appropriate location for Invoice and the other
>concepts that Mike added. The important distinction to remember
>is that, although every concept in the hierarchy is implicitly a
>class, the instances of those concepts are usually individuals, not
>classes. If a concept is located under “Class”, then all of its
>instances must be classes. So the class “Invoice” (whose instances
>are individual invoices) would be at a different location in the
>hierarchy. I suggest they go under “Proposition”
>
>"Invoice" and other items Mike put under “Class” were moved under
>“Proposition” (if a Proposition in SUMO must be a sentence-like
>entity or some combination of sentences, the Invoice and the elements
>of it can still be viewed conceptually as telegraphic communication
>representing the sentences “I request x”; The price I will pay for x is
>y”; “The number of x’s I want is z” , etc. So I think it
>fits under Proposition, but Adam or Ian can determine that more
>authoritatively. Under Proposition, I have added “Text-Abstract”
>and “TransitionRecordAbstract” (see the comments in the Protégé file
>for each of the classes I added); I also added “TransactionAmount”
>which is also a subclass of CurrencyMeasure. The following hierarchy
>would then hold:
>
>Proposition
> Text-Abstract
> TransactionRecordAbstract
> InvoiceAbstract
> LineItem
> Item
> Order
> ReceiptAdvice
> DespatchAdvice
> TransactionAmount
> CategoryTotal
> TaxAmounts
> TaxTotal
> LegalTotals
>
>
>The abstract objects that are whole object and may be represented as
>stand-alone documents have the relations:
>
>InvoiceAbstract representedBy Document
>Order representedBy Document
>ReceiptAdvice representedBy Document (assuming ReceiptAdvice
> can be a stand-alone document)
>DespatchAdvice representedBy Document (assuming DespatchAdvice
> can be a stand-alone document)
>
>
>========================================
>(6) parts of an Invoice
> We need to add the SUMO relation properPart, which was left out
>of the Protégé version of SUMO 1.48. I have added that
>relation. Then, as a subrelation of properPart I have created
>“subtext” which relates a Text (abstract or physical) to
>some part of that text. “Proper Part” is a term of art
>meaning that the part is not the whole thing there is
>some other part as well.
> A subtext of an abstract text would be an abstract text,
>a subtext of a physical text would be a physical text. The
>axioms to express this have not yet been added.
>
> . . . then we have the relation:
> Invoice subText TransactionAmount
> (i.e. a transaction amount is a subtext of an Invoice).
>
> One can also add relations to any other parts of an invoice
>using this relation. In Protégé the relation can be made to be
>optional or mandatory if we decide that some quoted “TransactionAmount”
> some sum of money -- **must** be present
>in a valid invoice, then we can make the above relation mandatory
>by clicking the “required” button in Protégé for the relation
>at the class of “Invoice”.
>
>
> It is probably advisable to create more specific subclasses
>of “Document” to represent the various types of documents that
>get created and transmitted in a transaction. The relations
>then would refer to the more specific physical document types
>that are created.
>
> It is not necessary to have parallel abstract and physical classes
>for every symbolic or prepositional concept in an ontology,
>but where the concepts are central to a particular application
>such as commercial transactions, I expect that the parallel
>classes will be more helpful than burdensome. This is a
>judgment each ontology builder has to make for her/his
>own purposes. It can be modified after experience, but changes
>later on could be time-consuming.
>
>
> Pat
>
>=============================================
>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)
|