Concerning two issues -- the definition of an invoice,
and the Protege version of the starter UBL ontology
built on SUMO. (01)
(1) a dictionary definition says: (02)
"an itemized bill for goods sold or services provided, containing
individual prices, the total charge, and the terms." (03)
1.a. The essential element is that this is a request for payment.
If that is agreed, it will affect how the Invoice is represented.
Is there any disagreement? (04)
1.b. The dictionary says that the goods were "provided" -- past
tense. Is it possible to send an invoice requesting payment before
goods were shipped? Can shipment be contingent on prior payment
as requested in an invoice? (05)
1.c. It seems that all invoices are sent in response to a
purchase order. Are there any exceptions? (06)
---------------------
NOTE: it would probably help to have someone get a few invoices and
scan them for us to have as references. The only invoices I ever
encounter myself are those sent along with a shipment. I'm not
even sure that those are properly considered as "invoices", since they
are not typically a request for payment, but merely an itemization of
what was sent. Can anyone get some examples?
=================================================== (07)
(2) Protege version: (08)
2.a. I have made a crude transcription of SUMO version 1.55 into
Protege, available at:
ftp://micra.com/ontolog/SUMO155.pprj
ftp://micra.com/ontolog/SUMO155.pont
ftp://micra.com/ontolog/SUMO155.pins (09)
The relations are incomplete in this Protege implementation --
the subrelations were not added in. Also, there are no
axioms. An important point is that the relations are
nt distinguished as to whether they are necessary or
optional -- for example, if a "part" relation is specified
on a class, it is not necessarily true that every instance
of the class has such a part. We can specify that relations
are necessary in Protege, if we decide as such. (010)
2.b. To the Protege version of SUMO 1.55 above I have added in
the classes that were added by Mike Daconta in his ubl-invoice-V01
ontology, and also the classes I described in my previous note.
This version is available as: (011)
ftp://micra.com/ontolog/UBLinv011.pprj
ftp://micra.com/ontolog/UBLinv011.pont
ftp://micra.com/ontolog/UBLinv011.pins (012)
In this version the SUMO ternary slots and binary functions were
represented more accurately, and the subrelations were added in.
This version also has a provision for representing synonyms or
referring to similar concepts in other languages or other ontologies.
See the "Entity" class for an example. (013)
============================================ (014)
I think two issues need to be discussed right away: whether to
represent both abstract and physical invoices, and how to represent
the parts of an invoice.
As to whether to have representations of both abstract and physical
"Invoice", I would strongly recommend that both be included. It is
not in general necessary to have both abstract and physical
representations of every text, but in a case, as we are dealing with
here, where the document itself if the main topic of an ontology (or
ontology module), I believe it will be useful to explicitly represent
all of the concepts that users will be considering on a regular basis. (015)
In Mike's implementation he creates relations corresponding to the
various parts of the invoice. An alternative could be to represent
the parts explicitly in the class hierarchy (as texts -- physical
and/or abstract) and relate them by a "part" relation. For example,
in SUMO there is a "subProposition" relation: (016)
"(&%subProposition ?PROP1 ?PROP2) means that ?PROP1 is a &%Proposition
which is a proper part of the &%Proposition ?PROP2. In other words,
&%subProposition is the analogue of &%properPart for chunks of
abstract content." (017)
If, as I suggest, there is a representation of the abstract
informational content of an invoice "InvoiceAbstract", then this
subproposition relation would be the link between the whole
invoice and it abstract parts.
There would be corresponding "part" relation for the physical
Invoice and its different data fields.
I prefer the use of the "part" relation for various reasons, but
one important reason is that the proliferation of relations that
are not needed can make an ontology harder to understand, and
correspondingly harder to use. (018)
Pat (019)
=============================================
Patrick Cassidy (020)
MICRA, Inc. || (908) 561-3416
735 Belvidere Ave. || (908) 668-5252 (if no answer)
Plainfield, NJ 07062-2054 || (908) 668-5904 (fax) (021)
internet: cassidy@xxxxxxxxx
============================================= (022)
================================= (023)
Kurt Conrad wrote:
> All,
>
> Peter and I set up the Invoice concept Wiki page. It can be found at
> http://ontolog.cim3.net/cgi-bin/wiki.pl?UblOntology/Invoice
>
> The approach that we took was to first consolidate the various
> definitions of Invoice that have been passed around. Once we have
> settled on the "official" Ontolog definition for invoice, we expect that
> the material copied from forum postings can be removed.
>
> We thought about trying to reflect some sort of structure (e.g., class
> hierarchy) either on the concept page or across concept pages. This
> proved to be problematic for a number of reasons. As a result, the Wiki
> page includes a Related Concepts section, but the concepts are only
> listed without any regard to the ways that they are related.
>
> As we populated the Related Concepts section with examples, we
> identified a number of issues which should be addressed by the team in
> the near term. The most critical ones are:
>
> 1) Determining the naming conventions that we will use for the
> concepts. A number of alternatives are listed on the Wiki page.
>
> 2) Ensuring that the concepts that we are defining map cleanly to the
> concepts identified by the UBL committee. Toward this end, I populated
> the Related Concepts section with the concepts listed in the appropriate
> version 0.7 analysis spreadsheet.
>
> A Specifications has also been provided. Although it isn't populated at
> this time, we expect it to contain (or link) to matching representations
> (Protoge, KIF, XML Schema, etc.).
>
> Please review this page with an eye to using the resulting page
> structure as a model for "all" concept pages.
>
> /s/ kwc 2003.07.14 23:41
>
>
> _________________________________________________________________
> 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
>
> (024)
_________________________________________________________________
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 (025)
|