ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Core Component Representation

To: cassidy@xxxxxxxxx, "[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>, "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Adam Pease <adampease@xxxxxxxxxxxxx>
Date: Thu, 26 Feb 2004 07:53:28 -0800
Message-id: <5.0.0.25.0.20040226074843.01dd8e30@xxxxxxxxxxxxxxxxxx>
Pat,
   As you know, but just for the record, I don't think our job is to 
represent text fields, but rather the semantic content of an order.  I 
believe if we represent a particular coding of an order document, as 
opposed to, or in addition to, the order itself, we're going to be adding 
confusion, rather than making a clear recommendation to the UBL folks.
   This group has discussed this issue on several occasions.  I though we 
had consensus that we would be representing orders and invoices, rather 
than codings of orders and invoices, but I could be mistaken.  It would be 
beneficial if anyone else recalls a consensus, so that we don't confuse our 
customers, or spend time revisiting this issue repeatedly.    (01)

Adam    (02)

At 10:05 AM 2/26/2004 -0500, Patrick Cassidy wrote:
>Concerning representation of the UBL Core Components:
>
>    Adam Pease's note (Feb. 20) has given a good listing of the ultimate
>referents within SUMO for the UBL Core Components.  This is helpful.
>
>    My own interpretation of the Core Component specification is that the
>elements are almost all intended to represent text fields within
>business documents.  The ultimate referents of the text fields are,
>I think, pretty much as Adam has listed.  But I think it will also
>be essential to represent the text fields directly.
>      We do not, of course, need to adhere strictly to the UBL specification
>in creating our own representation of business-related informational 
>entities ­ my suggestions do not correspond one-to-one to the UBL 
>structures -- but I think that there is a good reason to create concept 
>classes that have most or all of the conceptual content of the UBL 
>concepts, because they do to some extent capture concepts that will be 
>useful in reasoning about transactions,
>and especially about documents transmitted for use in transactions.
>
>    There has already been a great deal of work on representing the format
>of texts -- HTML, for example.  XML tried to capture more of the
>semantics, but it still is  concerned largely with text.  As I interpret
>it, the UBL specification is trying to capture even more of the
>semantics of texts -- specifically business documents -- that XML.
>I think our goal is to complete the semanticization by linking all
>these texts and their content and referents to an upper ontology.
>
>   But texts they are, as best I can tell.  So in addition to
>providing links to the ultimate referents, as Adam has done,
>I wold recommend that we also deal explicitly with the issue
>of representing fields in a business document.
>
>    Given that interpretation, as best I can tell, the semantics of
>the UBL core components appears to be something like this:
>
>(1) The Fundamental elements are all text fields in a document.  These
>correspond to classes, and the UBL name of each ends in “.Type”:
>
>         Measure
>         Quantity
>         Amount
>         Indicator
>         Numeric
>         DateTime
>
>(2)  These text field classes appear to be subclasses of “Text” in the 
>Core Components.
>The link is only explicit for “Indicator”, “Numeric” and “DateTime”, but 
>implied for the other three classes
>
>(3)  each of these text fields is formatted.  The three “quantity” fields 
>have component parts (subfields):
>
>         Field                   has subfields
>         ------------    -------------------------------------
>         Measure Content MeasureUnit
>         Quantity        Content QuantityUnit
>         Amount  Content AmountCurrency
>
>   In each of these cases, “Content” is a numeric field
>   The differences in the unit subfields of these classes seem to come 
> from their different
>   roles (locations) in an invoice or order document: as I interpret them:
>
>     Quantity is used to specify the number of units of an item ordered.
>     Measure is used to specify numerical measured attributes of objects 
> in an order (e.g. diameter or length of a pipe, size of a container).
>     Amount is a currency amount, which may or may not have the currency 
> unit explicitly mentioned.
>
>(4)  The Units are also text fields, and the text symbols representing 
>those units are all instances of “Code”, which is a special kind of text 
>string which must be on a CodeList approved by a Agency.
>
>(5) Though not explicit in the UBL scheme, it seems best to treat  Code as 
>a subclass of Identifier, which is also a text field.  In this 
>interpretation, an Identifier may or may not be restricted to words on a 
>list approved by an Agency, whereas a code must
>be on such a list.
>
>(6) A Code is an element of a Code List.
>
>(7) A Code List is part of (specified by) a Code List Scheme.  It is 
>written in a specific language.
>
>(8) A Code List Scheme is a Type of Identification Scheme.  An 
>Identification Scheme must also be approved by an Agency.
>
>(9) A BinaryObject is anything that is represented as sequences of 
>bytes.  It may represent a Text.  The implication is that this is always a 
>computer file, but for precision it is best to think of it as a more 
>general binary-encoded object with Computer files as subtypes.  I have 
>included ComputerFile as a subclass of BinaryObject in the
>SMINK009 ontology.
>
>(10)  All of these text fields ***refer conceptually*** to entities 
>(numbers, objects) that
>are not texts, but are not explicitly described as Types within the Core 
>Components
>specification.
>
>********************************************
>
>Using this interpretation, I have created classes and instances that I 
>think best represent the conceptual content of the core components, and 
>have linked them to the SUMO/MILO ontology.  The resulting files are 
>posted at the links below.
>
>In doing the linkage, I have found it useful to add some concepts that are 
>peripheral to the core components themselves.  I hope we can focus on the 
>UBL core components and not be distracted by the peripherally related concepts.
>
>    In the SMINK009min ontology, the UBL concepts are represented as
>instances of ":UBL-Synonym" and when one views those in the
>"Instances" window of Protege, one will see the ontology class which
>is the synonymous concept for the UBL concept.  In the
>"samin009min.txt" file, the list of UBL concepts starts after
>the string "<module>UBL-Synonyms"
>
>
>===================================================
>
>     The files available are:
>     ftp://micra.com/ontolog/smink009min.zip    --  the WinZipped Protege
>                               files for the combined SUMO, Mid-Level,
>                               and Invoices ontology:  SMINK009min
>                              This version has “Context” removed to avoid 
> distraction by
>                                   issues not of immediate concern.
>     ftp://micra.com/ontolog/skifcore.zip    --  the WinZipped Protege
>                               SKIFcore.* files (3) for the base Protege
>                               ontology required to import a SKIF file
>                               using the SKIF tab
>     ftp://micra.com/ontolog/skif_tab.jar    --  the jar file for the
>                                SkifTab plugin which will import a SKIF
>                                file into Protege (if it follows the
>                                SUMO-SKIF conventions)
>     ftp://micra.com/ontolog/samin009min.zip     --  a zipped text file
>                                 "samin006.txt", which is the
>                                SKIF-format file for the combined
>                                SUMO, Mid-Level,  and Invoices
>                                ontologies (the SKIF-text version of
>                                Protege ontology SMINK006)
>
>
>     As usual, I am eager to get any kind of feedback, positive or negative,
>about the ontology or its Protege or SKIF representations.
>I will also be happy to answer general questions about Protege or the
>plugin that converts SKIF to Protege formats.
>
>    If we can block out an hour or so sometime I will be happy to do a quick
>run through on these suggestions.  If Peter sets it up, we can use
>the tight VNC so that I can show how they are displayed in Protégé.
>If someone will load the file into another browser, I will also be happy to
>look at that display together with the group.
>
>      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)
<Prev in Thread] Current Thread [Next in Thread>