Folks,
Here are my answers for Pat. (01)
Here are the existing terms I've identified already in SUMO or a domain
ontology, with the relevant line number from the file. As far as I can
see, all the term additions suggested by Pat are not necessary. Below,
Merge.txt is SUMO. (02)
>Classes:
>Statement (03)
not sure if this is a logical statement or something like a billing
statement. Proposition (Merge.txt 2731-2745) addresses the former,
FinancialText addresses the latter (Mid-level-ontology.txt 4423-4424) (04)
>Wood (05)
Mid-level-ontology.txt 3040-3041 (06)
>Document
>Address (07)
GeographicArea covers a location (Merge.txt 10188-10193) Address
(Mid-level-ontology.txt 1330-1331) is a relational attribute for the postal
information about a particular location (08)
>And relations:
>hasName (09)
see names (Merge.txt 3311-3315) (010)
>address (011)
see address (Mid-level-ontology.txt 1326-1327) (012)
>The "address" relation is very basic, and should be filled out with more
>detail for realistic applications.
>
> (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 (013)
They should be Corporations (Merge.txt 12141-12144) (014)
>. 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)
I agree. Good addition. (016)
> 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. (017)
I agree. The formalization I started was just a sketch, and omitted these
statements, which you rightly point out are important. (018)
>(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. (019)
Yes, I intended ManufacturedProduct to be a subclass of Product, but had
not yet formalized it in the invoice ontology sketch. (020)
>I have also changed the propositions:
>(address SpecialistWindowsPLC "Snowhill Works")
>(address JerryBuilderPLC "Marsh Lane")
>
>to:
>(address SpecialistWindowsPLC SnowhillWorks)
>(address JerryBuilderPLC MarshLane)
>
> . . . 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. (021)
yes, good fix (022)
>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.
>
>(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. (023)
good fix, that was a typo on my part (024)
>(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. (025)
hasName is redundant and I believe should not be added (026)
> (2) reordered the other propositions into blocks having the
>same first argument.
>
>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.
>
>(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. (027)
I agree, although I probably should have broken out this domain ontology
information separately from the Invoice ontology, since we can't possibly
cover all the things that might be line items in an invoice. (028)
>(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. (029)
The idea of creating a "summary" predicate from which the more complex
axiom is inferrable, is a good idea. However, since items don't have the
same value in all invoices, I'd recommend making this a ternary
relation. Also, we attempted to eliminate initial prepositions from
relation names in SUMO. So, I'd suggest (030)
(instance unitValueInInvoice TernaryRelation)
(domainSubclass unitValueInInvoice 1 Product)
(domain unitValueInInvoice 2 CurrentMeasure)
(domain unitValueInInvoice 3 Invoice)
(documentation unitValueInInvoice "unitValueInInvoice relates each instance
of a class of an article of commerce to its value in the context of a
particular invoice.") (031)
> The relation and associated axiom would be:
>
>(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")
>
>(=>
> (hasUnitValue ?X ?Y)
> (forall ?P
> (=>
> (instance ?P ?X))
> (monetaryValue ?P ?Y)))
>
>Then the proposition added to the JoineryObject-236WV
>Proposition block would be:
> (hasUnitValue JoineryObject-236WV (MeasureFn 102.50 BritishPound))
>
>For the illustrative example below I have left the axiom as Adam
> wrote it.
>
>(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?
>
>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.
>
>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.
> (032)
I'd suggest that we use SUMO's ConstantQuantity and change the argument
type of the relation to (033)
(domain quantityInEvent 2 ConstantQuantity) (034)
In that way, we can handle packages, weights, counts or any other measure,
without changing or biasing the relation. (035)
I really appreciate Pat's concrete efforts on the ontology. Unfortunately,
we do differ on the use of Protege. Protege will not show ternary
relations, such as unitValueInInvoice, so I believe for that reason, as
well as others, it's inappropriate as a modeling tool for this effort. (036)
Adam (037)
>(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.
>
>(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
>
> . . . in the directory http://micra.com/ontolog/skiftab/
>
>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.
>
>(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/
>
>
>**************************************************************
>
>;; <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
>
>;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>;; INVOICES ;;
>;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
>;; 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'
>
>
>;; PJC Jan 13, 2004
>;; BEGIN Definitions added by PJC to those proposed by Adam Pease
>;; *****************************************************
>
>(subclass Statement Proposition)
>(documentation Statement "A communication between two agents asserting
>what the speaker considers as a fact.")
>
>(subclass LivingTree Plant)
>(documentation LivingTree "A plant having a permanently woody stem or
>trunk, usually developing branches at a distance from the ground.")
>
>(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.")
>
>(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.")
>
>(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.")
>
>;; note that the order of the arguments for the
>;; hasName relation is the opposite of that for 'name'
>
>(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.")
>
>(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.")
>
>
>;; *****************************************************
>;; End definitions added by PJC
>
>;; BEGIN Propositions and axioms suggested by Adam Pease.
>;; The order of the propositions has been changed from
>;; the original.
>; Modified Jan. 10, 2004
>;; ********************************************
>
>(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.")
>
>(=>
> (instance ?I Invoice)
> (exists (?EV)
> (and
> (instance ?EV Selling)
> (refers ?I ?EV))))
>
>
>(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.")
>
>(=>
> (quantityInEvent ?P ?Q ?OBJ)
> (exists (?INST)
> (equal ?Q
> (CardinalityFn
> (KappaFn ?INST
> (and
> (instance ?INST ?OBJ)
> (patient ?P ?INST)))))))
>
>
>(subclass Softwood Wood)
>(documentation Softwood "Wood obtained from trees classified in the family
>of Softwoods or gymnosperms. Examples include scrub pine, spruce and cedar.")
>
>(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.")
>
>(=>
> (and
> (instance ?H Hardwood)
> (instance ?S Softwood)
> (measure ?H
> (DensityFn ?MASSH ?VOLUME))
> (measure ?S
> (DensityFn ?MASSS ?VOLUME)))
> (greaterThan ?MASSH ?MASSS))
>
>
>(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.")
>
>;; <assertion>
>;; ------------------------------------------------------
>;; Instance level content
>;; The following propositions describe a sample invoice,
>;; referring to a fictional transaction, for illustrative
>;; purposes -- PJC
>
>;; not yet formalized: Delivery Doc: DEL-03/55-712
>;; not yet formalized: Your Order No: S03-034257
>;; not yet formalized: Contact: Eva Brick
>
>(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.")
>
>(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.")
>
>;; 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
>
>(=>
> (instance ?X JoineryObject-236WV)
> (monetaryValue ?X (MeasureFn 102.50 BritishPound)))
>
>(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.")
>
>(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.")
>
>(instance JerryBuilderPLC CognitiveAgent)
>(hasName JerryBuilderPLC "Jerry Builder plc")
>(address JerryBuilderPLC MarshLane)
>(documentation JerryBuilderPLC "The buyer in the
>commercial transaction JoineryPurchase-2003-00645.")
>
>(instance SpecialistWindowsPLC CognitiveAgent)
>(hasName SpecialistWindowsPLC "Specialist Windows plc")
>(address SpecialistWindowsPLC SnowhillWorks)
>(documentation SpecialistWindowsPLC "The seller in the
>commercial transaction JoineryPurchase-2003-00645.")
>
>(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.")
>
>(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.")
>
>(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.")
>
>(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.")
>
>(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.")
>
>(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.")
>
>;; </assertion>
>
>;; End Propositions and axioms suggested by Adam Pease
>;; ********************************************
>
>;; END FILE
>
>
>
>_________________________________________________________________
>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 (038)
_________________________________________________________________
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 (039)
|