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)
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”:
>(2) These text field classes appear to be subclasses of “Text” in the
>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
>(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
>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.
>MICRA, Inc. || (908) 561-3416
>735 Belvidere Ave. || (908) 668-5252 (if no answer)
>Plainfield, NJ 07062-2054 || (908) 668-5904 (fax)
>Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>Shared Files: http://ontolog.cim3.net/file/
>Community Wiki: http://ontolog.cim3.net/wiki/ To Post:
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (04)