In follow-up to our conference call Thursday
I have transcribed the 92 complexTypes from the
UBL_Library_0p70_Reusable.xsd file into Protege format,
and added them to the Protege file I previously modified.
Kurt Conrad (I think) pointed out that the xsd files
have the most detailed and authoritative representations,
so I decided to try to get those representations into
Protege format. One issue we discussed in the
7-17 conference call was how to relate the Order line item to
the Invoice line item, and Kurt pointed out that these items
already have unique identifiers, so we only need to
create the relationship and can anchor it to the
unique identifiers. I have not done that specific task --
there are some questions I want to think about first. (01)
The new Protege files are at: (02)
ftp://micra.com/ontolog/UBLinv013.pins
ftp://micra.com/ontolog/UBLinv013.pins
ftp://micra.com/ontolog/UBLinv013.pins (03)
These UBL Complex Type classes are all gathered temporarily
under the class "TransactionEntity". This class
organization is not intended to be a proper categorization,
it is only a temporary first step in getting those concepts
into Protege. As an additional step I have clustered some
of the complex types under common parent classes, such
as "Addressing" and "OrderCharges" to keep the similar
class types together.
The classes that Mike Daconta added are still there,
under "TransactionRecordAbstract" (an abstract transaction
record). The "Invoice" is present in duplicate classes,
which can help us in the discussion until we decide
on the final form. Mike's version is renamed "InvoiceAbstract"
and the transcription of the xsd file is "InvoiceType".
Mike has referenced the class types for the "range"
variable of the associated concepts, but in the transcription
these types have not yet been specified (though they are
implied in the name of the slot).
Once again it is necessary to recall that these at
present are represented as abstract conceptual items,
which may have one or more physical representations
in actual documents, on paper, microfilm, in a
computer memory, on disc. etc. We can create
parallel classes of physical objects corresponding
to these abstract concepts, but since the physical
objects can be of many forms, I think it will be
simpler at first to work with the abstract objects. (04)
The properties and associations are represented as
Protege slots, but they are still in exactly the same
terminology as in the xsd file, and their semantics
have not yet been clarified. Recall that in Protege the
slots that have a small "S" icon in a aqua green box are
the slots defined directly on that class, and the ones
with the white box are inherited from a higher class.
A few of the slots had to have their names changed because
they conflicted with the names of classes, which is a no-no
in Protege. I have also done a similar transcription for
the "invoice" xsd file and the "order" xsd file, and those
are present as classes "InvoiceType" and "OrderType"
under "TransactionRecordAbstract". (05)
This transcription has helped me recognize some
of the issues that need to be resolved in order to
make an ontology with the proper semantics for these
concepts. Among other things, the proper cardinality for
the slots needs to be reviewed. In the transcription I
automatically made all the slots 0 or 1 ("0..1" in UML).
I only reviewed the cardinality for the classes
"InvoiceType" and "OrderType". The xsd file is not
identical to the UML gif representation in one respect --
instead of 0 and 1, the xsd file often just states the
minimum of 0. IN some cases no cardinality is stated
in the xsd file. So these cardinalities have to be
reviewed manually both against the xsd file and the UML
gif. (06)
The "allowed classes" for the slots were in most cases
just set to "UBLattribute" as a temporary parking place.
These have to be manually resolved when the semantics are
understood. The descriptions in the xsd file were rather
brief, and I do not fully understand the intended meanings
of many of the concepts. It would be really helpful if we
had real live examples of the kinds of documents and
data fields that these concepts refer to. (07)
Before I try to refine this transcription, I would like
to know if others think that this procedure would help
in doing what we are trying to do. Perhaps it is not
best to try to replicate the UBL classes directly in this
fashion. (08)
But as I mentioned I have found the exercise useful to
try to understand the semantics of these data elements.
There are a number of issues raised. If anyone wants to
discuss this directly or through the list, I will try to
respond to the extent that I can. Since I have almost
no experience with handling documents of this type,
I would need advice from those who have such experience to
know just what the data really means, and only then
would be able to suggest a proper representation. (09)
Pat (010)
=============================================
Patrick Cassidy (011)
MICRA, Inc. || (908) 561-3416
735 Belvidere Ave. || (908) 668-5252 (if no answer)
Plainfield, NJ 07062-2054 || (908) 668-5904 (fax) (012)
internet: cassidy@xxxxxxxxx
============================================= (013)
_________________________________________________________________
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 (014)
|