MDaconta@xxxxxxx wrote:
> Hi All,
>
> Ok, here is an initial whack at an Invoice ontology.
> See http://www.daconta.net/UBLOntology.html.
> (01)
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., (02)
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 (03)
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. (04)
************
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.
************ (05)
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. (06)
*************************
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”? (07)
“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”. (08)
********************************** (09)
The specific changes to Mike’s version 0.1 ontology added
to version 0.11 were:
=========================
(1) Under “Abstract” I have added the classes: (010)
AbstractSymbol
Text-Abstract
AbstractGraphicalObject (011)
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. (012)
(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. (013)
The relations of these general categories of abstract object
would then be: (014)
AbstractSymbol representedBy ContentBearingObject
Text-Abstract representedBy Text
AbstractGraphicalObject representedBy PictorialObject (015)
** and the inverses **
PictorialObject containsInformation AbstractGraphicalObject
Text containsInformation Text-Abstract
ContentBearingObject containsInformation (AbstractSymbol (016)
Proposition AbstractGraphicalObject)
[i.e. a ContentBearingObject may contain information
from one or more of those three categories]. (017)
[[“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.]]
================== (018)
(3) Product – I changed this to “ProductObject” because services are
often considered
as Products of service companies. This terminology avoids confusion. (019)
(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”. (020)
==============
(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” (021)
"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: (022)
Proposition
Text-Abstract
TransactionRecordAbstract
InvoiceAbstract
LineItem
Item
Order
ReceiptAdvice
DespatchAdvice
TransactionAmount
CategoryTotal
TaxAmounts
TaxTotal
LegalTotals (023)
The abstract objects that are whole object and may be represented as
stand-alone documents have the relations: (024)
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) (025)
========================================
(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. (026)
. . . then we have the relation:
Invoice subText TransactionAmount
(i.e. a transaction amount is a subtext of an Invoice). (027)
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”. (028)
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. (029)
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. (030)
Pat (031)
=============================================
Patrick Cassidy (032)
MICRA, Inc. || (908) 561-3416
735 Belvidere Ave. || (908) 668-5252 (if no answer)
Plainfield, NJ 07062-2054 || (908) 668-5904 (fax) (033)
internet: cassidy@xxxxxxxxx
============================================= (034)
_________________________________________________________________
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 (035)
|