In response to Adam's note: (01)
Adam Pease wrote: (02)
> Peter,
> I think the time for yet more planning and deliberation has passed.
> If people start on the terms provided, at the very least it will provide
> concrete action, education and progress towards our objective. Once
> people are engaged in formalization, we may wish to plan or replan, but
> a start at "prototyping" with the current list will still be useful
> effort. I say let's get started. If I see concrete effort, I can
> afford to stay engaged in this effort.
>
> . . . . . .
> Adam
> (03)
The suggestions I have about this formalization are appended below. (04)
--
=============================================
Patrick Cassidy (05)
MICRA, Inc. || (908) 561-3416
735 Belvidere Ave. || (908) 668-5252 (if no answer)
Plainfield, NJ 07062-2054 || (908) 668-5904 (fax) (06)
internet: cassidy@xxxxxxxxx
============================================= (07)
Formalizing Invoices:
This note is a response to Adam's message suggesting certain
propositions to begin the formalization of Invoices, with one
fictional example of an Invoice for illustrative purposes.
In this note I will only suggest a reorganization and
supplementation of Adam's content, for the purpose of making
it consistent with the format of the SUMO 1.55 files, which
can be automatically imported into Prote'ge' for visualization
with that tool. If this suggested format is acceptable to
the group, I will add more content along with any that Adam or
others suggest. The issues that I think need attention are
numbered below. (08)
Since I assume that we have agreed to use SUMO as the upper ontology
that will contain the base concepts for defining the Invoice ontology,
we need to fix on the version of SUMO that will be used
for that purpose. Since I have been working with SUMO 1.55, I will
respond to Adam's suggestions based on the use of SUMO 1.55 as the
base ontology. (09)
NOTE on terminology: I am using "proposition" to refer to the
SKIF statements that begin with a non-logical relation, and "axiom"
to refer to SKIF statements beginning with "=>" (implies)
or "<=>"(if and only if, iff), or "not". I will be happy to use other
terminology if it is more congenial to the group. (010)
(1) In order to integrate the axioms Adam has suggested with the
Existing SUMO 1.55, we need to add a few classes not already in that
Ontology, as well as two relations (these may exist in a later version
of SUMO - Perhaps Adam can point us to the proper version). I have
added the minimum content, without elaboration, since Adam may already
have more details on these required concepts. If details are not
already present in one of Adam's ontologies, I will add them to make
the additional concepts more distinct. (011)
Classes:
Statement
Wood
Document
Address (012)
And relations:
hasName
address (013)
The "address" relation is very basic, and should be filled out with more
detail for realistic applications. (014)
(2) The references to the buyer and seller in the fictional instance
(JerryBuilderPLC and SpecialistWindowsPLC) do not specify the
classes of which these are instances (although it is implied in the
"agent" proposition that they are agents), so I have added explicit
propositions that classify these as CognitiveAgents. Also, the
buying and selling aspects of the transaction are specified as
subprocesses of the transaction, but not identified as to which is
the buying and which is the selling, so I have added "instance"
propositions to make that explicit. (015)
In general, I think it is a good practice when introducing
instances of concepts into an assertional database to explicitly
specify the class for each instance, unless one is using a
knowledge-acquisition program that can reliably deduce the class.
I do not know what programs Adam uses in his database creation,
but for our purposes I would suggest that we assume nothing about
the inference engine and be as explicit as possible
in creating assertions. (016)
(3) I have changed "ManufacturedProduct" to "Product", as that seems
to be the term in SUMO 1.55 that refers to objects created by
manufacture and intended to be sold. If a ManufacturedProduct is
intended to be different from the SUMO 1.55 "Product", perhaps Adam
can create a definition with the appropriate distinctions. (017)
I have also changed the propositions:
(address SpecialistWindowsPLC "Snowhill Works")
(address JerryBuilderPLC "Marsh Lane") (018)
to:
(address SpecialistWindowsPLC SnowhillWorks)
(address JerryBuilderPLC MarshLane) (019)
. . . to conform to the definition of the relation "address",
which has instance of Address rather than instance of strings
as its value. I am not sure if that is what Adam intended. (020)
In adding the class Address and relation address, I have used the
minimum detail, as Adam may already have more detailed
definitions in his other ontologies, which we might prefer to
use. The current definitions are added only to allow proper
representation of the suggested propositions as addenda to the
existing SUMO 1.55 ontology. (021)
(4) I have also rearranged the line order of the propositions for
relation "quantityInEvent" to conform to the format in the SUMO 1.55
text file (which format is assumed by the SKIF-to-Prote'ge' conversion
routine I wrote). This doesn't affect the logical content.
The position integer (3) for the "domainSubclass" proposition was also
added to regularize that proposition. (022)
(5) In order to keep all propositions related to a specific entity
within a single block of consistent format, as is used in SUMO 1.55,
I have
(1) used a relation "hasName" in which the order of the
arguments is the opposite of that used by Adam for the "name" relation.
(2) reordered the other propositions into blocks having the
same first argument. (023)
The reordering into blocks is not logically necessary, but by
clustering of propositions related to entities with the
entity name being the first argument in each proposition, the
parsing of the proposition blocks becomes simpler, as I have found
for conversion of SKIF to Prote'ge'. This is in any case the format
used in SUMO 1.55, and I think it is at least as easy for a human
to understand as the alternative clustering (easier, I think).
To maintain the SUMO 1.55 format I have also added a
"documentation" proposition to each block. (024)
(6) Although it is not essential for this stage, if types of wood are
being represented, it would be reasonable to explicitly represent
trees here as well. The class "LivingTree" is added as a direct
subclass of "Plant". (Tree is already a class of Graphs). Further
elaboration, not done here to keep this note short, would specify
that wood is derived from trees. (025)
(7) The price of each instance of JoineryObject-236WV is specified by
an axiom in Adam's formalization, but it might be more perspicuous to
create a relation, e.g. "hasUnitValue", which states the same thing as
a one-line proposition. I believe that this tactic will make it
easier to relate to the UBL "BasePrice" concept, though it would
not be identical without further elaboration.
The relation and associated axiom would be: (026)
(instance hasUnitValue BinaryRelation)
(domainSubclass hasUnitValue 1 Product)
(domain hasUnitValue 2 CurrencyMeasure)
(documentation hasUnitValue "hasUnitValue relates each instance
of a class of an article of commerce to its value in some context,
e.g. selling price. The Product instance will typically be a package
sold as a unit, which may contain multiple exemplars of the
manufactured item. The context is not directly specified in the
relation") (027)
(=>
(hasUnitValue ?X ?Y)
(forall ?P
(=>
(instance ?P ?X))
(monetaryValue ?P ?Y))) (028)
Then the proposition added to the JoineryObject-236WV
Proposition block would be:
(hasUnitValue JoineryObject-236WV (MeasureFn 102.50 BritishPound)) (029)
For the illustrative example below I have left the axiom as Adam
wrote it. (030)
(8) An issue that I need more information on is the interpretation of
the UBL "Item". Each Item has an (optional) Pack.Size and
Pack.Quantity (number of individual items in each unit package sold).
Does anyone know the difference between these two Item properties? (031)
This will affect the interpretation of the relation "quantityInEvent"
proposed by Adam. I would imagine that for the purposes of a selling
event, the "quantity" referred to will be the number of packages,
rather than the number of individual items which may be contained in
the packages. Then the Product class will need further elaboration.
I would suggest creating a CommercialItem class as a subclass of
product, which is intended to have the properties of the Item
object class in UBL. (032)
The UBL property referring to units for selling line Items is
"Quantity", which is an integer. Does anyone know how one specifies
in UBL that a unit package contains, say, five pounds of potatoes?
I haven't found that kind of detail, and it may be that this is
something that is not formalized within the UBL specification. (033)
(9) To segregate these propositions and axioms from those of the base
SUMO 1.55 ontology, I have added a header comment field in the format
of the SUMO text files which serves to organize these statements into
a separate module "Invoices". The "includes" statements are probably
to some extent redundant, as some of the modules already include
others, but I am uncertain as to how the "includes" statements are
intended to be used in SUMO, so I included all SUMO modules.
The <assertion> tag was added to define the segment in which
the propositions refer to instances. This is useful in parsing.
These propositions and axioms can then be appended to the
existing SUMO 1.55 file to create the SKIF text file which is the
merger of these statements and SUMO 1.55. (034)
(10) With these modifications, the SUMO 1.55 text file with the appended
invoice propositions and axioms can be automatically imported into
Prote'ge'. The Prote'ge' files with these concepts included is contained
in the files: ("SKIN" = Sumo-Kif INvoice)
SKIN0001.pprj
SKIN0001.pins
SKIN0001.pont (035)
. . . in the directory http://micra.com/ontolog/skiftab/ (036)
NOTE: At this point the import program does not automatically fill
in the instance-level relations specified in the SKIF database, so
one will not find, for example, that Buying-2003-00645 is a subProcess
of JoineryPurchase-2003-00645. This functionality of the import
program needs to be added. (037)
(11) The resulting text of the suggested Invoice propositions and
axioms is appended below. The file containing the SUMO 1.55 text
with these propositions appended is "testin.kif" in the directory
http://micra.com/ontolog/skiftab/ (038)
************************************************************** (039)
;; <module>Invoices</module>
;; This module contains a set of propositions that were created as
;; part of the development of an Invoice ontology by the Ontolog
;; study group.
;; Started January 2004.
;; This is only an initial set of classes, relations, and axioms
;; for discussion.
;; Last edit January 13, 2004
;; BEGIN FILE (040)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; INVOICES ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (041)
;; INCLUDES 'BASE ONTOLOGY'
;; INCLUDES 'STRUCTURALONTOLOGY'
;; INCLUDES 'NUMERIC FUNCTIONS'
;; INCLUDES 'SET/CLASS THEORY'
;; INCLUDES 'UNITS OF MEASURE'
;; INCLUDES 'TEMPORAL CONCEPTS'
;; INCLUDES 'MEREOTOPOLOGY'
;; INCLUDES 'PROCESSES'
;; INCLUDES 'OBJECTS'
;; INCLUDES 'QUALITIES' (042)
;; PJC Jan 13, 2004
;; BEGIN Definitions added by PJC to those proposed by Adam Pease
;; ***************************************************** (043)
(subclass Statement Proposition)
(documentation Statement "A communication between two agents asserting
what the speaker considers as a fact.") (044)
(subclass LivingTree Plant)
(documentation LivingTree "A plant having a permanently woody stem or
trunk, usually developing branches at a distance from the ground.") (045)
(subclass Address Object)
(documentation Address "an Address is a location, which may be a
StationaryArtifact or a LandArea, where a CognitiveAgent may be found,
or a Post Office Box.") (046)
(subclass CommercialItem Product)
(documentation CommercialItem "An article of commerce sold as a unit,
corresponding to the 'Item' class used in the UBL specification. This
represents a 'package' for sale and may have any number of individual
manufactured objects in it, such as a pair of shoes, a bag of potatoes,
or a kit with several different types of items as components.") (047)
(subclass Wood Substance)
(documentation Wood "Wood is a natural substance obtained by
processing trees, typically by removing the outer portions of the
trunk or of thick branches. For commercial purposes Wood may be
considered as non-living. The 'Wood' (woody substance) which may
contain living cells in a living tree should therefore be labeled by a
different name.") (048)
;; note that the order of the arguments for the
;; hasName relation is the opposite of that for 'name' (049)
(instance hasName BinaryRelation)
(domain hasName 1 Entity)
(domain hasName 2 SymbolicString)
(documentation hasName "hasName relates an instance of an entity to a
string of linguistic characters used to reference the entity in
linguistic communication. The hasName relation is not a necessary
relation since not every entity is named by a SymbolicString and not
every SymbolicString is the label for an entity.") (050)
(instance address BinaryRelation)
(domain address 1 CognitiveAgent)
(domain address 2 Address)
(documentation address "address relates an instance of a CognitiveAgent
a the unique designation of a stationary artifact where that agent can
be contacted. This address includes buildings, room numbers, and mail
drop numbers, but excludes telephone numbers and other addresses that
are not stationary. This is not the most general type of address.") (051)
;; *****************************************************
;; End definitions added by PJC (052)
;; BEGIN Propositions and axioms suggested by Adam Pease.
;; The order of the propositions has been changed from
;; the original.
; Modified Jan. 10, 2004
;; ******************************************** (053)
(subclass Invoice Statement)
(documentation Invoice "A document which states that a buyer owes, or
does not owe, money for goods or services purchased from a seller.") (054)
(=>
(instance ?I Invoice)
(exists (?EV)
(and
(instance ?EV Selling)
(refers ?I ?EV)))) (055)
(instance quantityInEvent TernaryRelation)
(domain quantityInEvent 1 Process)
(domain quantityInEvent 2 Integer)
(domainSubclass quantityInEvent 3 Object)
(documentation quantityInEvent "(quantityInEvent ?PROC ?QUANT ?OBJ)
means that the number of &%Objects that are instances of ?OBJ that
participate in an event ?PROC in the role of &%patient is ?QUANT.") (056)
(=>
(quantityInEvent ?P ?Q ?OBJ)
(exists (?INST)
(equal ?Q
(CardinalityFn
(KappaFn ?INST
(and
(instance ?INST ?OBJ)
(patient ?P ?INST))))))) (057)
(subclass Softwood Wood)
(documentation Softwood "Wood obtained from trees classified in the
family of Softwoods or gymnosperms. Examples include scrub pine,
spruce and cedar.") (058)
(subclass Hardwood Wood)
(disjoint Hardwood Softwood)
(documentation Hardwood "Wood obtained from trees classified in the
family of Hardwoods, or angiosperms. Examples include oak, birch and
maple.") (059)
(=>
(and
(instance ?H Hardwood)
(instance ?S Softwood)
(measure ?H
(DensityFn ?MASSH ?VOLUME))
(measure ?S
(DensityFn ?MASSS ?VOLUME)))
(greaterThan ?MASSH ?MASSS)) (060)
(subclass JoineryObject-236WV Product)
(subclass JoineryObject-236WV Softwood)
(documentation JoineryObject-236WV "This is the class of objects, the
sale of certain instances of which is referred to in the sample
invoice JoineryInvoice-2003-00645, used in development of the Ontology
Invoice ontology.") (061)
;; <assertion>
;; ------------------------------------------------------
;; Instance level content
;; The following propositions describe a sample invoice,
;; referring to a fictional transaction, for illustrative
;; purposes -- PJC (062)
;; not yet formalized: Delivery Doc: DEL-03/55-712
;; not yet formalized: Your Order No: S03-034257
;; not yet formalized: Contact: Eva Brick (063)
(instance JoineryInvoice-2003-00645 Invoice)
(hasName JoineryInvoice-2003-00645 "IN 2003/00645")
(date JoineryInvoice-2003-00645 (DayFn 25 (MonthFn 2 (YearFn 2003))))
(refers JoineryInvoice-2003-00645 JoineryPurchase-2003-00645)
(documentation JoineryInvoice-2003-00645 "This is a sample invoice
used for illustrative purposes in development of the Ontology Invoice
ontology. All agents and events are fictional.") (064)
(instance JoineryPurchase-2003-00645 FinancialTransaction)
(date JoineryPurchase-2003-00645 (DayFn 3 (MonthFn 2 (YearFn 2003))))
(quantityInEvent JoineryPurchase-2003-00645 2 JoineryObject-236WV)
(documentation JoineryPurchase-2003-00645 "This is the selling event
referred to in the sample invoice JoineryInvoice-2003-00645, used in
development of the Ontology Invoice ontology. This is a fictional
event.") (065)
;; The Axiom below states that every instance of the class of objects
;; JoineryObject-236WV has the value GBP 102.5
;; see PJC note (7) above for an alternative representation (066)
(=>
(instance ?X JoineryObject-236WV)
(monetaryValue ?X (MeasureFn 102.50 BritishPound))) (067)
(instance Buying-2003-00645 Buying)
(subProcess Buying-2003-00645 JoineryPurchase-2003-00645)
(agent Buying-2003-00645 JerryBuilderPLC)
(documentation Buying-2003-00645 "The buying aspect of the
commercial transaction JoineryPurchase-2003-00645; the
transaction from the perspective of the buyer JerryBuilderPLC.") (068)
(instance Selling-2003-00645 Selling)
(subProcess Selling-2003-00645 JoineryPurchase-2003-00645)
(agent Selling-2003-00645 SpecialistWindowsPLC)
(documentation Selling-2003-00645 "The selling aspect of the
commercial transaction JoineryPurchase-2003-00645; the
transaction from the perspective of the seller SpecialistWindowsPLC.") (069)
(instance JerryBuilderPLC CognitiveAgent)
(hasName JerryBuilderPLC "Jerry Builder plc")
(address JerryBuilderPLC MarshLane)
(documentation JerryBuilderPLC "The buyer in the
commercial transaction JoineryPurchase-2003-00645.") (070)
(instance SpecialistWindowsPLC CognitiveAgent)
(hasName SpecialistWindowsPLC "Specialist Windows plc")
(address SpecialistWindowsPLC SnowhillWorks)
(documentation SpecialistWindowsPLC "The seller in the
commercial transaction JoineryPurchase-2003-00645.") (071)
(instance MarshLane Address)
(hasName MarshLane "Marsh Lane")
(located MarshLane NowhereNorfolk)
(postalCode MarshLane "NR18 4XX")
(documentation MarshLane "The fictional address of the buyer
JerryBuilderPLC in the fictional commercial transaction
JoineryPurchase-2003-00645.") (072)
(instance NowhereNorfolk City)
(located NowhereNorfolk NorfolkUK)
(documentation NowhereNorfolk "The fictional city where the buyer
JerryBuilderPLC in the fictional commercial transaction
JoineryPurchase-2003-00645 is located.") (073)
(instance NorfolkUK StateOrProvince)
(located NorfolkUK UnitedKingdom)
(documentation NorfolkUK "The fictional state where the buyer
JerryBuilderPLC in the fictional commercial transaction
JoineryPurchase-2003-00645 is located.") (074)
(instance SnowhillWorks Address)
(hasName SnowhillWorks "Snowhill Works")
(located SnowhillWorks LittleSnoringWhereshire)
(postalCode SnowhillWorks "SM2 3NW")
(documentation SnowhillWorks "The fictional address where the seller
SpecialistWindowsPLC in the fictional commercial transaction
JoineryPurchase-2003-00645 is located.") (075)
(instance LittleSnoringWhereshire City)
(located LittleSnoringWhereshire WhereshireUK)
(documentation LittleSnoringWhereshire "The fictional city where the
seller SpecialistWindowsPLC in the fictional commercial transaction
JoineryPurchase-2003-00645 is located.") (076)
(instance WhereshireUK StateOrProvince)
(located WhereshireUK UnitedKingdom)
(documentation WhereshireUK "The fictional state where the seller
SpecialistWindowsPLC in the fictional commercial transaction
JoineryPurchase-2003-00645 is located.") (077)
;; </assertion> (078)
;; End Propositions and axioms suggested by Adam Pease
;; ******************************************** (079)
;; END FILE (080)
_________________________________________________________________
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 (081)
|