Guide to payments ontology
Dave Reynolds
we developed in partnership with LeGSB. A couple of people pinged me to
ask about documentation so just wanted to say that a draft guide is up
at:
http://data.gov.uk/resources/payments
Dave
Kingsley Idehen
Links:
1. http://www.heppnetz.de/projects/goodrelations/
-- Regards, Kingsley Idehen President & CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Kingsley Idehen
Dave,
I've see the ontology namespace: http://reference.data.gov.uk/def/payment#, is now visible -- assuming I didn't overlook it prior to writing my earlier post :-)
Ivan Begtin
Here in Russia I am doing similar efforts to model russian procurement
procedures and results.
We have some russian specific experience that probably could help you
making this ontology more flexible
- it's not often but possible that payment could be from one payer to
multiple contractors using one purchase. It's mostly about historical
data about 4-7 years ago.
- we have multiple "good records" for each contract and each good
record is structure that contain:
-- name of good/service
-- procurement code (russian OKP classifier)
-- units of measurement code (russian OKEI classifier)
-- amount of items/services
-- price per item
-- total sum
- some contracts could have more than one "expendure line" (or "budget
line")
- if it's government contract it's important to include unique codes
of higher government body, since from time to time organizations could
be reorganized or to becode under another government body.
- we have some bit-like flags related to contract and payee. Like "Is
it small business?"
- each contract has at least a few dates:
- date of signature
- date of registration
- date of planned execution (it's not actual date but year/month
combination)
- date of execution
- there are more than one invoice and each contract record has also
invoice records which being added after invoice passed through
treasury. But invoice information and details are never public
- each contract has at least one "contract line". It's similar to
budget line and contains information about amount of money reserved
for this contract for next years and from that budget type it comes.
Here in Russia we have: federal budget, budget of federation subject
(regional), pension budget, non-budget sources.
Right now we are discussing about modelling "contract specifications".
It's more details description of goods records that allows to get more
information about specific contract types.
For example - for cars this specification will include:
- producer;
- originating country
- horsepower
- model name
and so on...
But we still far from OWL/RDF specifications since here in Russia only
a few persons ever undestand and like Semantic Web.
Best Regards,
Ivan Begtin
Russiang public procurement monitoring - http://www.rosspending.ru
Dave Reynolds
On Sun, 2010-11-28 at 01:40 -0800, Ivan Begtin wrote:
> Hi, Dave!
>
> Here in Russia I am doing similar efforts to model russian procurement
> procedures and results.
> We have some russian specific experience that probably could help you
> making this ontology more flexible
> - it's not often but possible that payment could be from one payer to
> multiple contractors using one purchase. It's mostly about historical
> data about 4-7 years ago.
Interesting.
We separate the purchase from the payment. There is nothing to stop
multiple payments referencing the same purchase but each payment is, by
definition, a transfer to a single payee . There is no restriction in
the ontology that any of purchase/invoice/contract be unique to a single
payment so there can be many-to-1 relationships.
> - we have multiple "good records" for each contract and each good
> record is structure that contain:
> -- name of good/service
> -- procurement code (russian OKP classifier)
> -- units of measurement code (russian OKEI classifier)
> -- amount of items/services
> -- price per item
> -- total sum
Such "good records" would correspond to instances of payment:Purchase in
this ontology.
There is no detailed machinery for describing purchases in the payments
ontology. This is partly a matter of principle (ontologies of this sort
should be tightly focused and this one focuses on payments information,
as would be recorded in a general ledger, not on purchases) and partly a
matter of practicality (none of the UK information being published
includes this information, a pretty major omission IMHO).
Creating and/or referencing an ontology for describing the good/service
purchased in more detail would be quite straight forward. Arguably
GoodRelations provides some basis for that.
> - some contracts could have more than one "expendure line" (or "budget
> line")
Indeed, there is a many to one relationship between ExpenditureLines and
Payments in this ontology.
> - if it's government contract it's important to include unique codes
> of higher government body, since from time to time organizations could
> be reorganized or to becode under another government body.
In the linked data world we achieve this by using URIs to denote
organizations. In cases where there is a unique internal code then that
can be used to construct the URI but can be made explicit using
org:identifier.
> - we have some bit-like flags related to contract and payee. Like "Is
> it small business?"
In our case, again thanks to ontology modularization, we recommend use
of org: for organizations. That allows for use of either class
hierarchies or SKOS classification schemes (via org:classification) for
categorization of the type of organization.
Typically in our case such information would be obtained from different
sources and linked to the payment information through shared use of
URIs.
> - each contract has at least a few dates:
> - date of signature
> - date of registration
> - date of planned execution (it's not actual date but year/month
> combination)
> - date of execution
As with purchase information, contracts information should be handled by
a separate ontology. The payment:contract property can then be used to
link the Payment to a structure representation of the contract.
> - there are more than one invoice and each contract record has also
> invoice records which being added after invoice passed through
> treasury. But invoice information and details are never public
True here as well.
> - each contract has at least one "contract line". It's similar to
> budget line and contains information about amount of money reserved
> for this contract for next years and from that budget type it comes.
> Here in Russia we have: federal budget, budget of federation subject
> (regional), pension budget, non-budget sources.
Yes. We are not representing budget reservations here, again we are just
focused on the payments. The budget from which the payment, when it is
made, comes is representable using payment:expenditureCategory which
typically points to a cost centre within an analysis/budget hierarchy.
> Right now we are discussing about modelling "contract specifications".
> It's more details description of goods records that allows to get more
> information about specific contract types.
There are also plans in the UK to publish contract information but at
present I don't know if anyone sees value in publishing that in
structured form. If there were we'd be happy to help develop a contracts
ontology that would be compatible with the payments ontology.
> For example - for cars this specification will include:
> - producer;
> - originating country
> - horsepower
> - model name
> and so on...
For good/services, as opposed to contracts, I'd recommend taking a look
at the GoodRelations ontology [1] if you haven't already done so. They
are developing a range of companion ontologies for particular domains
include the "Vehicular Sales Ontology" which might be relevant to the
above example.
Dave
Christopher Gutteridge
this data? That would help clarify how it should be described.
--
Christopher Gutteridge -- http://id.ecs.soton.ac.uk/person/1248
You should read the ECS Web Team blog: http://blogs.ecs.soton.ac.uk/webteam/