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. (01)
Adam (02)
At 01:37 PM 1/9/2004 -0800, Peter Yim wrote:
>Thanks, Adam.
>
>Actually, after you left the planning session yesterday, the discussion
>had come up that, maybe, starting to formalize from terms in the "UBL
>Invoice" is not optimal -- this has actually been one thing that had
>bothered me all along, for not having put in the time to plan out the
>entire approach prior to beginning formalization work.
>
>UBL builds upon the ebXML CC's (Core Components). As such, our purpose
>might be better served by starting to formalize the CC terms -- Core
>Component Types (CCT) first, then Basic BIEs (Basic Business Information
>Entities), Aggregate BIEs (ABIE), and then UBL documents (like invoice,
>... etc.) If ebXML/UBL were looked at as "informal ontologies" (I know
>this term does not exist for you, but let's not argue over that for now),
>their authors have already put in tremendous effort identifying and
>structuring their "upper" and "lower" ontology, in a way.
>
>Could we take a step back and look over the latest UBL release
>(http://ontolog.cim3.net/cgi-bin/wiki.pl?UblRelease1_0) again in light of
>the above comment?
>
>Regards,
>PPY
>--
>
>Adam Pease wrote Thu, 08 Jan 2004 14:44:40 -0800:
>
>>Folks,
>> As promised from today's telecon, here are three things
>>1. My start at formalizing invoice information
>>2. A list of terms we could start formalizing
>>3. The methodological outline I suggest
>>Adam
>>=================== Item #1 ==========================
>>=================== Formalization ====================
>>; This document is released into the public domain with the caveat
>>; that users of this work must give proper credit in any publication
>>; about the work to the author - Adam Pease (apease@xxxxxxxxxxxxxxxxxx)
>>;
>>; This document is an attempt to fomalize the content of the example
>>; JoineryInvoice.JoineryInvoiceInstance1.html from the UBL effort
>>; domain ontology content
>>(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)
>>(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.")
>>(domain quantityInEvent 1 Process)
>>(domain quantityInEvent 2 Integer)
>>(domainSubclass quantityInEvent Object)
>>(=>
>> (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.")
>>(disjoint Hardwood Softwood)
>>(subclass Hardwood Wood)
>>(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))
>>;------------------------------------------------------
>>; Instance level content
>>(instance JoineryInvoice-2003-00645 Invoice)
>>(name "IN 2003/00645" JoineryInvoice-2003-00645)
>>(date JoineryInvoice-2003-00645 (DayFn 25 (MonthFn 2 (YearFn 2003))))
>>(instance JoineryPurchase-2003-00645 FinancialTransaction)
>>(subprocess Buying-2003-00645 JoineryPurchase-2003-00645)
>>(subprocess Selling-2003-00645 JoineryPurchase-2003-00645)
>>(refers JoineryInvoice-2003-00645 JoineryPurchase-2003-00645)
>>(agent Buying-2003-00645 JerryBuilderPLC)
>>(name "Jerry Builder plc" JerryBuilderPLC)
>>(address JerryBuilderPLC "Marsh Lane")
>>(instance MarshLane Address)
>>(name "Marsh Lane" MarshLane)
>>(instance NowhereNorfolk City)
>>(located MarshLane NowhereNorfolk)
>>(instance NorfolkUK StateOrProvince)
>>(located NowhereNorfolk NorfolkUK)
>>(located NorfolkUK UnitedKingdom)
>>(postalCode MarshLane "NR18 4XX")
>>(agent Selling-2003-00645 SpecialistWindowsPLC)
>>(name "Specialist Windows plc" SpecialistWindowsPLC)
>>(address SpecialistWindowsPLC "Snowhill Works")
>>(instance SnowhillWorks Address)
>>(name "Snowhill Works" SnowhillWorks)
>>(instance LittleSnoringWhereshire City)
>>(located SnowhillWorks LittleSnoringWhereshire)
>>(instance WhereshireUK StateOrProvince)
>>(located LittleSnoringWhereshire WhereshireUK)
>>(located WhereshireUK UnitedKingdom)
>>(postalCode SnowhillWorks "SM2 3NW")
>>; not yet formalized: Delivery Doc: DEL-03/55-712
>>; not yet formalized: Your Order No: S03-034257
>>; not yet formalized: Contact: Eva Brick
>>(subclass JoineryObject-236WV ManufacturedProduct)
>>(subclass JoineryObject-236WV Softwood)
>>(quantityInEvent JoineryPurchase-2003-00645 2 JoineryObject-236WV)
>>(=>
>> (instance ?X JoineryObject-236WV)
>> (monetaryValue ?X (MeasureFn 102.50 BritishPound)))
>>(date JoineryPurchase-2003-00645 (DayFn 3 (MonthFn 2 (YearFn 2003))))
>>=================== Item #2 ==========================
>>=================== UBL term list ====================
>>UBL Name BIE Dictionary Entry Name UBL Definition
>>Invoice Invoice. Details the document that describes the finanical
>>commitment of the Order
>>ID Invoice. Identifier the unique number assigned to the invoice by
>>the seller (invoicer)
>>StatusCode Invoice. Status. Code "Identifies the status of the
>>document with regard to change from its original state; 'original',
>>'copy', 'revision' or 'cancellation'. Original is as first sent; a copy
>>is typically sent on request if the original has been misplaced; a
>>revision is a document that contains a change from the original, e.g.
>>new, deleted or amended item lines; cancellation is cancellation of whole
>>document (for normal order changes and cancellations the respective
>>documents should be used)"
>>GloballyUniqueIdentifier Invoice. Globally Unique_Identifier. Text
>>"a computer generated unique identifier for the document, which is
>>guaranteed to be unique"
>>IssueDate Invoice. Issue. Date the date when the invoice was issued
>>TypeCode Invoice. Type. Code identifies the type of the Invoice by
>>a code.
>>Note Invoice. Note. Text contains any free form text pertinent to
>>the entire document or to the document message itself. This element may
>>contain notes or any other similar information that is not contained
>>explicitly in another structure.
>>TaxPointDate Invoice. Tax Point. Date "the date of the invoice for
>>tax purposes, in accordance with the applicable tax regulation."
>>InvoiceCurrencyCode Invoice. Invoice_Currency. Code the currency in
>>which the Invoice is presented. This may be the same currency as the
>>pricing or as the tax.
>>TaxCurrencyCode Invoice. Tax_Currency. Code the currency in which
>>the tax on the Invoice is presented. This may be the same currency as the
>>pricing or as the Invoice itself.
>>PricingCurrencyCode Invoice. Pricing_Currency. Code the currency in
>>which the prices are specified. This may be the same currency as the
>>Invoice itself or as the tax.
>>LineItemCountQuantity Invoice. LineItem_Count. Quantity the number
>>of line items
>>OrderReference Invoice. Order Reference Provides a means of
>>associating an Invoice with one or more Orders
>>DespatchReference Invoice. Despatch_ Reference Provides a means of
>>associating an Invoice with one or more Despatch Advices
>>ReceiptReference Invoice. Receipt_ Reference Provides a means of
>>associating an Invoice with one or more Receipt Advices
>>AdditionalDocumentIdentification Invoice. Additional_ Document
>>Identification Provides other means of identifying an Invoice
>>BuyerParty Invoice. Buyer Party associates the Order with
>>information about the buyer involved in the transaction.
>>SellerParty Invoice. Seller Party associates the Order with
>>information about the seller involved in the transaction.
>>Delivery Invoice. Delivery associates the overall invoice with the
>>details of a delivery (or deliveries)
>>PaymentMeans Invoice. Payment Means associates the invoice with the
>>expected means of payment.
>>PaymentTerms Invoice. Payment Terms associates the invoice with the
>>payment terms applicable/offered.
>>AllowanceCharge Invoice. Allowance Charge associates the invoice
>>with an overall charge or allowance.
>>ExchangeRate Invoice. Exchange Rate "associates the invoice with an
>>exchange rate. In any one invoice there is only one exchange rate needed,
>>either between invoicing at tax currency, or between pricing and invoice
>>totalling."
>>TaxTotals Invoice. Tax Totals associates the invoice with summary
>>information for a particular tax.
>>LegalTotals Invoice. Legal Totals associates the invoice with a set
>>of totals required for the invoice to be a legal document.
>>InvoiceLine Invoice. Invoice Line an invoice has one or more
>>invoice lines
>>
>>=================== Item #3 ==========================
>>=================== Methodology ======================
>>- Extract nouns and verbs from a source text
>>- Find classes in SUMO for the nouns and verbs
>>- Record a mapping as being either equal, subsuming or instance.
>> * type a single word that relates to the UBL term in the "SUMO term"
>> or "English Word" text areas in the SUMO browser
>>- Create a subclass of SUMO if it's a subsuming mapping
>>- Add properties to the subclass
>> * reusing SUMO properties
>> * extending SUMO properties by creating a &%subrelation of an existing
>> property
>>- Add English definition to the class
>> * define constraints that express how the subclass is more specific
>> than the superclass
>>- Express the classes and properties in KIF and begin creating axioms,
>>based on the English definitions created previously
>>_________________________________________________________________
>>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
>>
>
>_________________________________________________________________
>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)
|