Disruptive Semantics for the Financial World

Hands-on tutorial

To apply the Accounting Ontology by yourself in your own enterprise, you are welcome to load the following basic SPARQL queries about gist:Accounting in any triple store of your choice. Indeed, your are about to build more efficient applications driven by a Knowledge Graph.

Therefore, we expect you to learning by doing since this presentation is a hands-on approach.

Remark: the following namespaces will be used throughout the tutorial:

Prefix:	Long Form
rdf:	http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs:	http://www.w3.org/2000/01/rdf-schema#
xml:	http://www.w3.org/XML/1998/namespace#
xsd:	http://www.w3.org/2001/XMLSchema#
owl:	http://www.w3.org/2002/07/owl#
gist:	https://ontologies.semanticarts.com/gist/
acc:	https://semanticworld.com/accounting/sparql/dataset/

1.1 Creation of magnitudes

Prepping

1.1.1 The first step

We are going to focus on the class gist:Magnitude since all the data needed for accounting purpose are quantitative ones. So, let us create some magnitudes:

This first insert query ex001.ttl is defining two magnitudes, and each one of them equal to 100 as a decimal Value:

# filename: ex001.ttl

acc:_magnitude1_URI rdf:type gist:SourceMagnitude,
      owl:NamedIndividual .
acc:_magnitude1_URI gist:decimalValue "100"^^xsd:double.

acc:_magnitude2_URI rdf:type gist:SourceMagnitude,
      owl:NamedIndividual .
acc:_magnitude2_URI gist:decimalValue "100"^^xsd:double.

Note

gist:SourceMagnitude is a sub-class of the previously mentionned gist:Magnitude.

By the way, the loaded magnitudes don't have any unit of measure yet. And, for the purpose of this tutoriel we want to assign each magnitude to a different currency unit.

1.2 Currency Unit

1.2.1 Assign the magnitudes

Let's assume together that a "Currency Exchange Agency" is requiring an accurate accounting data management system.
We are going to create two currency units: "USdollar" and "Euro" with each above magnitude having its own unit of measure. So, it will allow this "Currency Exchange Agency" to convert the two currencies into one another.

Our second insert query ex002.ttl will do that for us.

# filename: ex002.ttl

acc:_USDollar rdf:type acc:CurrencyUnit ,
      owl:NamedIndividual  .
acc:_USDollar rdfs:label  "USdollars" ;
      acc:convertToUSDollar "1"^^xsd:double. ;
      gist:hasBaseUnit acc:_USDollar .

acc:_Euro rdf:type acc:CurrencyUnit ,
      owl:NamedIndividual  .
acc:_Euro rdfs:label "€uros" ;
      acc:convertToUSDollar "0.93"^^xsd:double. ;
      gist:hasBaseUnit acc:_Euro .

acc:_magnitude1_URI gist:hasFixedUoM acc:_USDollar ;
      rdfs:label  "$100 USD".

acc:_magnitude2_URI gist:hasFixedUoM acc:_Euro ;
      rdfs:label  "€100 Euros".

Note

The property acc:convertToUSDollar is a sub-property of gist:convertToBase. At the time of writing this article my today's conversion rate is about $1USD equal to €0.93Euro.
The property gist:hasBaseUnit is used to set the two currencies as base units of their owns.
The property gist:hasFixedUoM is a sub-property of gist:hasUoM. Because a Currency Unit isn't just like any other regular unit of measure.

1.2.2 A query for magnitudes

We can query now the two magnitudes in a single union sparql query as follow:
This query ex003.rq will select each magnitude's URI local name with its decimal value and its label.

# filename: ex003.rq

SELECT ?Magnitude1 ?decimalValue1 ?label1 ?Magnitude2 ?decimalValue2 ?label2
WHERE
{
  {?Magnitude1 rdf:type gist:SourceMagnitude;
               gist:decimalValue ?decimalValue1;
               gist:hasFixedUoM acc:_USDollar;
               rdfs:label ?label1.}
UNION
  {?Magnitude2 rdf:type gist:SourceMagnitude;
              gist:decimalValue ?decimalValue2;
              gist:hasFixedUoM acc:_Euro;
              rdfs:label ?label2.}
}

The result is:

Magnitude1	decimalValue1	label1	Magnitude2	decimalValue2	label2
_magnitude1_URI	"1.0E2"	"$100 USD"
			_magnitude2_URI	"1.0E2"	"€100 Euros"

1.2.3 Available conversions

Because, the conversion rate were already inserted in the second insert query ex002.ttl we are able to convert the two currencies into one another.
The next query ex004.rq will select the magnitude1's URI local name, then convert it in Euro. And at the same time, it will select the magnitude2's URI local name, then convert it in USdollar.

# filename: ex004.rq

SELECT ?Magnitude1 ?label1 ((?decimalValue1 * ?ConversionRate) AS ?ConvertedInEuro) ?Magnitude2 ?label2 ((?decimalValue2 / ?ConversionRate) AS ?ConvertedInDollar)
WHERE
{
  {?Magnitude1 rdf:type gist:SourceMagnitude;
               gist:decimalValue ?decimalValue1;
               gist:hasFixedUoM acc:_USDollar;
               rdfs:label ?label1.
  acc:_Euro acc:convertToUSDollar ?ConversionRate.}
UNION
  {?Magnitude2 rdf:type gist:SourceMagnitude;
              gist:decimalValue ?decimalValue2;
              gist:hasFixedUoM acc:_Euro;
              rdfs:label ?label2.
  acc:_Euro acc:convertToUSDollar ?ConversionRate.}
}

The result is:

Magnitude1	label1	ConvertedInEuro	Magnitude2	label2	ConvertedInDollar
_magnitude1_URI	"$100 USD"	"9.3E1"
			_magnitude2_URI	"€100 Euros"	"1.075E2"

1.3 Business Model

1.3.1 Commission rate

So far, the currency exchange commission rate isn't defined yet.

Thus, this next insert query ex005.ttl will add a commission of 2%. You understand too that this commission rate will be added to the previously converted amounts.
As this is how the "Currency Exchange Agency" makes Money.

# filename: ex005.ttl

acc:_USDollar acc:commissionToBase "1.02"^^xsd:double.

acc:_Euro acc:commissionToBase "1.02"^^xsd:double.

Note

The property acc:commissionToBase being another sub-property of gist:convertToBase.

1.3.2 Buy / Sell

The "Currency Exchange Agency" has now the ability to display on its desk in front office the buying and selling prices to its clients.

First, let's display the Buy/Sell amounts to European tourists (or clients owning Euros). This query ex006.rq will do that for us.

# filename: ex006.rq

SELECT ?Magnitude1 ?decimalValue1 ?label1 ((?decimalValue1 * ?ConversionRate) AS ?EquivalentInEuro) ((?decimalValue1 * ?ConversionRate * ?CommissionRate) AS ?BuyingPrice) ((?decimalValue1 * ?ConversionRate / ?CommissionRate) AS ?SellingPrice)
WHERE
{
  ?Magnitude1 rdf:type gist:SourceMagnitude;
               gist:decimalValue  ?decimalValue1;
               gist:hasFixedUoM acc:_USDollar;
               rdfs:label ?label1.
  acc:_Euro acc:convertToUSDollar ?ConversionRate.
  acc:_USDollar acc:commissionToBase ?CommissionRate.
}

The result is:

Magnitude1	decimalValue1	?label1	EquivalentIn€uro	BuyingPrice(€)	SellingPrice(€)
_magnitude1_URI	"1.0E2"	"$100 USD"	"9.3E1"	"9.486E1"	"9.117E1"

Second, let's display the Buy/Sell amounts to American tourists (or clients owning USD). This query ex007.rq (almost identical to ex006.rq will work just fine again.

# filename: ex007.rq

SELECT ?Magnitude2 ?decimalValue2 ?label2 ((?decimalValue2 / ?ConversionRate) AS ?EquivalentInUSD) (((?decimalValue2 / ?ConversionRate) * ?CommissionRate) AS ?BuyingPrice) ((?decimalValue2 / ?ConversionRate / ?CommissionRate) AS ?SellingPrice)
WHERE
{
  ?Magnitude2 rdf:type gist:SourceMagnitude;
              gist:decimalValue ?decimalValue2;
              gist:hasFixedUoM acc:_Euro;
              rdfs:label ?label2.
  acc:_Euro acc:convertToUSDollar ?ConversionRate.
  acc:_Euro acc:commissionToBase ?CommissionRate.
}

The result is:

Magnitude2	decimalValue2	?label2	EquivalentInUSD	BuyingPrice($)	SellingPrice($)
_magnitude2_URI	"1.0E2"	"€100 Euros"	"1.075E2"	"1.098E2"	"1.054E2"

A knowledge graph is a model of a knowledge domain. The more understanding you have about it, the more robust will you develop its reliable Graph.

'Everything should be made as simple as possible, but not simpler.'
—ALBERT EINSTEIN

Then, in order to map all business objects and concepts of accounting an enterprise works with, together with their interrelations, we are going to use the classes and properties presented in the PARTI visual.

2.1 Event

2.1.1 Offer

Act I (scene 1)

The following insert query ex008.ttl is offering a sell of $100USD.

# filename: ex008.ttl

acc:ExchangeMoneyOffer1_URI rdf:type gist:Offer ,
			  owl:NamedIndividual .
acc:ExchangeMoneyOffer1_URI rdfs:label  "Offer to sell the amount of $100USD in exchange of Euros"  ;
			gist: isAbout acc:_magnitude1_URI .

acc:startTimeInstant_Selling_100USD rdf:type gist:TimeInstant ,
		  owl:NamedIndividual .
acc:startTimeInstant_Selling_100USD rdfs:label  "StartDate for exchanging 100 USD" .
acc:startTimeInstant_Selling_100USD gist:localDateTime "2020-04-13T00:00:00"^^xsd:DateTime.

acc:endTimeInstant_Selling_100USD rdf:type gist:TimeInstant ,
		  owl:NamedIndividual .
acc:endTimeInstant_Selling_100USD rdfs:label "EndDate for exchanging 100 USD" .
acc:endTimeInstant_Selling_100USD gist:localDateTime "2020-04-14T00:00:00"^^xsd:DateTime.

acc:ExchangeMoneyOffer1_URI gist:actualStart acc:startTimeInstant_Selling_100USD .
acc:ExchangeMoneyOffer1_URI gist:actualEnd acc:endTimeInstant_Selling_100USD .

acc:_AdminExecutiveOfficer gist:create acc:ExchangeMoneyOffer1_URI .

Note

We used the property gist:isAbout as a mean to say that acc:ExchangeMoneyOffer_URI_1 is concerningacc:_magnitude_URI_1.
We defined a acc:startTimeInstant and aacc:EndTimeInstant for that particular selling offer.
Then, we set the acc:actualStart and theacc:actualEnd for the Currency Exchanger's offer URI: acc:ExchangeMoneyOffer_URI_1.
The very last line, is referring to the officer who created that offer.

The next insert query ex009.ttl is offering a buy of 100USD.

# filename: ex009.ttl

  acc:ExchangeMoneyOffer2_URI rdf:type gist:Offer ,
  			  owl:NamedIndividual .
  acc:ExchangeMoneyOffer2_URI rdfs:label "Offer to buy the amount of $100USD with Euros" ;
  			gist:isAbout acc:_magnitude1_URI .

  acc:startTimeInstant_Buying_100USD rdf:type gist:TimeInstant ,
  			  owl:NamedIndividual .
  acc:startTimeInstant_Buying_100USD rdfs:label "StartDate for exchanging 100 USD" .
  acc:startTimeInstant_Buying_100USD gist:localDateTime "2020-04-13T00:00:00"^^xsd:DateTime.

  acc:endTimeInstant_Buying_100USD rdf:type gist:TimeInstant ,
  			  owl:NamedIndividual .
  acc:endTimeInstant_Buying_100USD rdfs:label "EndDate for exchanging 100 USD" .
  acc:endTimeInstant_Buying_100USD gist:localDateTime "2020-04-14T00:00:00"^^xsd:DateTime.

  acc:ExchangeMoneyOffer2_URI gist:actualStart acc:startTimeInstant_Buying_100USD .
  acc:ExchangeMoneyOffer2_URI gist:actualEnd acc:endTimeInstant_Buying_100USD .

  acc:_AdminExecutiveOfficer gist:create acc:ExchangeMoneyOffer2_URI .

The same logic is applied here than ex008.ttl

Act I (scene 2)

Let's display the two offers that we've inserted. This query ex010.rq will select the offer's URI local name, its label, its actual start, its actual end and its conversion rate.

# filename: ex010.rq

SELECT ?OfferURI ?label ?WhatMagnitude ?actualStart ?actualEnd ?Creator
WHERE
{
?OfferURI rdf:type gist:Offer;
          rdfs:label ?label;
               gist:actualStart ?StartOffer;
               gist:actualEnd ?EndOffer;
               gist:isAbout ?WhatMagnitude.
?StartOffer gist:localDateTime ?actualStart .
?EndOffer gist:localDateTime ?actualEnd .
?Creator gist:create ?OfferURI .
}

The result is:

OfferURI	Offer's_label	actualStart	actualEnd	Creator
ExchangeMoneyOffer1_URI	Offer to sell $100USD	"2020-04-13T00:00:00"	"2020-04-14T00:00:00"	_AdminExecutiveOfficer
ExchangeMoneyOffer2_URI	Offer to buy $100USD with Euros	"2020-04-13T00:00:00"	"2020-04-14T00:00:00"	_AdminExecutiveOfficer

Act I (scene 3)

Furthermore, we are going to create two more offers ex011.ttl and ex012.ttl. We will do again what we did for Magnitude1 but for Magnitude2. And simply by applying the same previous select query ex010.rq we'll get now displayed four offers.

The result is:

OfferURI	Offer's_label	actualStart	actualEnd	Creator
ExchangeMoneyOffer1_URI	Offer to sell $100USD	"2020-04-13T00:00:00"	"2020-04-14T00:00:00"	_AdminExecutiveOfficer
ExchangeMoneyOffer2_URI	Offer to buy $100USD with Euros	"2020-04-13T00:00:00"	"2020-04-14T00:00:00"	_AdminExecutiveOfficer
ExchangeMoneyOffer3_URI	Offer to sell €100 Euros	"2020-04-13T00:00:00"	"2020-04-14T00:00:00"	_AdminExecutiveOfficer
ExchangeMoneyOffer4_URI	Offer to buy €100 Euros with USD	"2020-04-13T00:00:00"	"2020-04-14T00:00:00"	_AdminExecutiveOfficer

2.1.2 Purchase

We assume now that some clients are changing their currencies at the "Currency Exchange Agency".

Act II (scene 1)

A purchase occurs when a client accepts an offer. It isn't regarded as a transaction yet, nevertheless it can be considered as the first step (panel) for any actual payment.
The next query ex013.ttl is going to insert the necessary and sufficient triples for recording a purchase of $100USD by a client with some Euros.

# filename: ex013.ttl

  acc:buyingUSDPurchase_Client_ID_1 rdf:type acc:BuyingUSDPurchase ,
  			  owl:NamedIndividual.

  acc:buyingUSDPurchase_Client_ID_1  rdfs:label "buying $USD with some Euros" ;
  					gist:basedOn acc:ExchangeMoneyOffer1_URI ;
  					gist:seller acc:_AdminExecutiveOfficer;
  					gist:buyer acc:_Client_ID_1 .

  acc:_Client_ID_1  gist:accept acc:ExchangeMoneyOffer1_URI.

  acc:timeInstant_2020April13_09:00_USDPurchase  rdf:type gist:TimeInstant ,
  		  owl:NamedIndividual .
  acc:timeInstant_2020April13_09:00_USDPurchase rdfs:label "Datetime of purchasing 100USD with Euros" .
  acc:timeInstant_2020April13_09:00_USDPurchase gist:localDateTime "2020-04-13T09:00:00"^^xsd:DateTime .

  acc:buyingUSDPurchase_Client_ID_1  gist::start acc:timeInstant_2020April13_09:00_USDPurchase ;
  			gist:end acc:timeInstant_2020April13_09:00_USDPurchase .

  acc:Obligation_to_Deliver_100USD_Client_ID_1 rdf:type acc:Obligation_to_Deliver1 ,
  			  owl:NamedIndividual .
  acc:Obligation_to_Deliver_100USD_Client_ID_1 rdfs:label "Obligation to deliver $100USD to client".
  acc:Obligation_to_Deliver_100USD_Client_ID_1 gist:assignedTo acc:_AdminExecutiveOfficer.

  acc:Obligation_to_pay_for_100USD_byClient_ID_1 rdf:type acc:Obligation_to_Pay1,
  			  owl:NamedIndividual .
  acc:Obligation_to_pay_for_100USD_byClient_ID_1 rdfs:label "Obligation to pay 100USD in € by client".
  acc:Obligation_to_pay_for_100USD_byClient_ID_1 gist:assignedTo acc:_Client_ID_1.

  acc:buyingUSDPurchase_Client_ID_1  gist:triggers acc:Obligation_to_Deliver_100USD_Client_ID_1 ,
  			acc:Obligation_to_pay_for_100USD_byClient_ID_1 .

Act II (scene 2)

Likewise this query ex014.ttl will insert the necessary and sufficient triples for recording a purchase of $100USD by the "Currency Exchange Agency" with some Euros.

# filename: ex014.ttl

acc:buyingUSDPurchase_Agence_URI rdf:type acc:BuyingUSDPurchase ,
			  owl:NamedIndividual.

acc:buyingUSDPurchase_Agence_URI rdfs:label "buying $USD with some Euros" ;
			gist:basedOn     acc:ExchangeMoneyOffer2_URI ;
			gist:seller acc:_Client_ID_2 ;
			gist:buyer acc:_AdminExecutiveOfficer .

acc:_Client_ID_1  gist:accept acc:ExchangeMoneyOffer2_URI .

acc:timeInstant_2020April13_09:00_USDPurchase  rdf:type gist:TimeInstant ,
			  owl:NamedIndividual.
acc:timeInstant_2020April13_09:00_USDPurchase rdfs:label "Datetime of purchasing $100USD with Euros" .
acc:timeInstant_2020April13_09:00_USDPurchase gist:localDateTime "2020-04-13T09:30:00"^^xsd:DateTime .

acc:buyingUSDPurchase_Agence_URI gist:start acc:timeInstant_2020April13_09:00_USDPurchase ;
			gist:end acc:timeInstant_2020April13_09:00_USDPurchase .

acc:Obligation_to_Deliver_100USD_Agence_URI rdf:type acc:Obligation_to_Deliver2 ,
			  owl:NamedIndividual .
acc:Obligation_to_Deliver_100USD_Agence_URI rdfs:label "Obligation to deliver 100USD to the Agence".
acc:Obligation_to_Deliver_100USD_Agence_URI gist:assignedTo acc:_Client_ID_2 .

acc:Obligation_to_pay_for_100USD_byAgence_URI rdf:type acc:Obligation_to_Pay2,
			  owl:NamedIndividual .
acc:Obligation_to_pay_for_100USD_byAgence_URI rdfs:label "Obligation by the Agence to pay in € for USD ".
acc:Obligation_to_pay_for_100USD_byAgence_URI gist:assignedTo acc:_AdminExecutiveOfficer .

acc:buyingUSDPurchase_Agence_URI gist:triggers acc:Obligation_to_Deliver_100USD_Agence_URI ,
			acc:Obligation_to_pay_for_100USD_byAgence_URI .

Note

The same logic will be applied for the remaining two purchases. Instead of purchasing $100 USD with some Euros, the two parties will purchase €100 Euros with some USD (alternatively):

Act II (scene 3)

The query ex015.ttl will insert the necessary and sufficient triples for recording a purchase of €100 Euros by a client with some USD.

Act II (scene 4)

The query ex016.ttl will insert the necessary and sufficient triples for recording a purchase of €100 Euros by the "Currency Exchange Agency" with some USD.

We are going to unpack the above purchases:

First we've created a purchase by using a sub-class of gist:Purchase.
We used the property gist:basedOn as a mean to relate a purchase to an offer.
We defined the "seller" with the propertygist:seller and the "buyer" with the property gist:buyer.
We have asserted that a particular client is accepting the "Currency Exchange Agency's offer".
We defined a startTimeInstant and aEndTimeInstant to each purchase.
We set the actualStart and theactualEnd for each purchase's URI.

Last but not least:

All purchases trigger some obligations that are assigned to the two parties: buyer/seller.

2.1.3 Movement

Basically, a movement is a change of "Possession" or "Location" without the change of "Ownership". It's usually a physical change of location.

For the sake of clarifying what a movement represents for the "Currency Exchange Agency"'s own business model, it's worth mentionning, first of all, that gist:Movement is a sublass of gist:Transaction that is of course a subclass of gist:Event as you know.

Second of all, be aware that this class gist:Movement has itself a sub-class that is named gist:Acquirement. And its particularity is that: gist:Acquirementis a subclass of both gist:Movement and gist:Transfer.

2.1.4 Transfer

Act II (scene 5)

Fundamentally, a transfer defines the change of "Ownership" without the change of "Possession".

Nevertheless, gist:Transfer and gist:Movement have a common sub-class: gist:Acquirement.
Therefore, we will consider that a payment (in other words here: a change of currency) to the "Currency Exchange Agency" or by it, will immediately implies a change of "Possession" and "Ownership".

The query ex017.ttl will create two "types" of acquirements: one for the "Currency Exchange Agency" and one for its clients.

# filename: ex017.ttl

acc:PaymentForAquirementByAgency_URI rdf:type gist:Acquirement ,
	  owl:NamedIndividual .

acc:PaymentForAquirementByAgencyClients_URI rdf:type gist:Acquirement ,
		  owl:NamedIndividual.

2.1.5 Allocation

Act II (scene 6)

Allocation defines a movement that has no effect on any other party.

In order to demonstrate it, we are going to create two accounts for the "Currency Exchange Agency" using the gist:Account class.
In the meantime, the following internal policy is being defined as such: "Only the acc:_Account_Number_URI1 will be credited by the allocated Money". And keep in mind, that an employee will be assigned to allocate the Money on behalf of the "Currency Exchange Agency".

The query ex018.ttl is going to create the two above accounts. The first one must be guaranteed by a bank, the second one shall be considered as a "Virtual" Cashbox.

# filename: ex018.ttl

acc:_Currency_Exchange_Agency_URI a gist:Organization;
		 gist:identifiedBy acc:_Currency_Exchange_Agency_ID;
 gist:owns acc:_Account_Number_URI1;
 gist:owns acc:_Account_Number_URI2.

acc:_Account_Number_URI1 rdf:type acc:GuaranteedBankAccount;
 gist:hasMagnitude acc:magnitude_of_Account_Number_URI1.
acc:magnitude_of_Account_Number_URI1 gist:decimalValue "0"^^xsd:double.

acc:_Account_Number_URI2 rdf:type acc:VirtualCashBox;
 gist:hasMagnitude acc:magnitude_of_Account_Number_URI2.
acc:magnitude_of_Account_Number_URI2 gist:decimalValue "100"^^xsd:double.

acc:_Currency_Exchange_Agency_ID gist:uniqueText "Currency_Exchange_Agency_ID".

Note

We used the two classes acc:GuaranteedBankAccount and acc:VirtualCashBox as sub-classes of gist:Account.
The property gist:owns has been applied to define the ownership of the two accounts.
The magnitude's decimal value of the acc:_Account_Number_URI2 may be considered as loan or as (private) equity. It can be modeled either ways.

The next query ex019.rq will select the local names for the two accounts and their respective magnitudes.

# filename: ex019.rq

SELECT ?BankAccount ?Amount1 ?VirtualCashBox ?Amount2
WHERE
{
  {
  acc:_Currency_Exchange_Agency_URI gist:owns ?BankAccount .
  ?BankAccount rdf:type acc:GuaranteedBankAccount .
  ?BankAccount gist:hasMagnitude ?magnitude .
  ?magnitude gist:decimalValue ?Amount1 .
  }
  UNION
  {
  acc:_Currency_Exchange_Agency_URI gist:owns ?VirtualCashBox .
  ?VirtualCashBox rdf:type acc:VirtualCashBox .
  ?VirtualCashBox gist:hasMagnitude ?magnitude .
  ?magnitude gist:decimalValue ?Amount2 .
  }
}

The result is:

?BankAccount	?Amount1	?VirtualCashBox	?Amount2
_Account_Number_URI1	"0.0E0"
		_Account_Number_URI2	"1.0E2"

To allocate the Money, we'll use the two following sparql queries:
A first query ex020.rq will update the amount to be credited in the first account and the other one ex021.rq will remove the amount from the second account.

# filename: ex020.rq

DELETE { ?magnitude gist:decimalValue ?Amount1 }
INSERT { ?magnitude gist:decimalValue "100"^^xsd:double }
WHERE { acc:_Currency_Exchange_Agency_URI gist:owns ?BankAccount .
        ?BankAccount rdf:type acc:GuaranteedBankAccount .
        ?BankAccount gist:hasMagnitude ?magnitude .
        ?magnitude gist:decimalValue ?Amount1 .
      }

Here is the second query ex021.rq.

# filename: ex021.rq

DELETE { ?magnitude gist:decimalValue ?Amount2 }
INSERT { ?magnitude gist:decimalValue "0"^^xsd:double
WHERE { acc:_Currency_Exchange_Agency_URI gist:owns ?VirtualCashBox .
        ?VirtualCashBox rdf:type acc:VirtualCashBox .
        ?VirtualCashBox gist:hasMagnitude ?magnitude .
        ?magnitude gist:decimalValue ?Amount2 .
      }

After allocation, the same query ex019.rq will give us this result now:

?BankAccount	?Amount1	?VirtualCashBox	?Amount2
_Account_Number_URI1	"1.0E2"
		_Account_Number_URI2	"0.0E0"

2.2 Liability

Act III (scene 1)

The second panel of a purchase is its actual payment. Remember that any purchase triggers an obligation for the two parties: buyer/seller.
Therefore the two bellow queries are completing the transaction query ex017.ttl.

2.2.1 Obligation to deliver

The query ex022.ttl discharges the Agency's client (acc:_Client_ID_1) to pay in exchange of $100USD.

# filename: ex022.ttl

  acc:PaymentForAquirementByAgencyClients_URI rdfs:label "The uri's transaction that discharges the Agency's client to pay for $100USD" ;
        gist:dischargeFrom acc:Obligation_to_pay_for_100USD_byClient_ID_1 .

  acc:timeInstant_URI_of_the_actual_payment1 rdf:type gist:TimeInstant ,
        owl:NamedIndividual .

  acc:timeInstant_URI_of_the_actual_payment1 rdfs:label "DateTime of the actual payment" ;
        gist:localDateTime "2020-04-13T09:00:01"^^xsd:DateTime .

  acc:PaymentForAquirementByAgencyClients_URI gist:start acc:timeInstant_URI_of_the_actual_payment1 ;
        gist:end acc:timeInstant_URI_of_the_actual_payment1 .

2.2.2 Obligation to pay

The query ex023.ttl discharges the Agency's manager (acc:_AdminExecutiveOfficer) to deliver $100USD to its Client.

# filename: ex023.ttl

  acc:PaymentForAquirementByAgency_URI rdfs:label "The uri's transaction that discharges the Agency to deliver $100USD to its Client" ;
        gist:dischargeFrom  acc:Obligation_to_Deliver_100USD_Client_ID_1 .

  acc:timeInstant_URI_of_the_actual_payment1 rdfs:label "DateTime of the actual payment" ;
        gist:localDateTime "2020-04-13T09:00:01"^^xsd:DateTime .

  acc:PaymentForAquirementByAgency_URI gist:start acc:timeInstant_URI_of_the_actual_payment1 ;
        gist:end acc:timeInstant_URI_of_the_actual_payment1 .

Note

The three queries; ex017.ttl, ex022.ttl and ex023.ttl may better be grouped into a single one.

2.3 State

Act III (scene 2)

In the previous (Act III scene 1) we've already completed the "Transaction" by its actual payment1. As you may have noticed there isn't any “State” class that would define the ideas of “Ownership” and “Possession”. Instead, those ideas resides rightly now in the predicates associated with the gist:Transaction classes. You can read more about it; the gist:accounting's diagram explains it all.

Basically, using a predicate like gist:dischargeFrom opens up new ways to differentiate the actual status of instances within the gist:Transaction class.

2.3.1 Ownership

Anyway, it's easy to select instances coming from a Transfer or a Movement or both.

Just a simple query like ex024.rq will let you know the "inferred" purchases within the Transfer's class.

# filename: ex024.rq

  SELECT ?PurchaseInstanceName
  WHERE
  {
    ?PurchaseInstanceName rdf:type gist:Transfer .
  }

2.3.2 Possession

Likewise, the query ex025.rq will let you know the "inferred" purchases within the Movement's class.

# filename: ex025.rq

  SELECT ?PurchaseInstanceName
  WHERE
  {
      ?PurchaseInstanceName rdf:type gist:Movement .
  }

Note

In case of instances being part of the gist:Acquirement class, they will be classified as part of both classes namely: gist:Transfer and gist:Movement.

2.4 Resource

Any source or supply from which benefit is produced is considered as a resource.

Act IV (scene 1)

The gist:Accounting ontology is set to calculate now the net income for the "Currency Exchange Agency" that has been generated immediately after payment1. This query ex026.rq will do it:

# filename: ex026.rq

SELECT (SUM ((?decimalValue1 * ?ConversionRate * ?CommissionRate) - (?decimalValue1 * ?ConversionRate)) as ?Net_Income_in_Euro)
WHERE
{
  ?transaction  rdf:type gist:Acquirement ;
                gist:dischargeFrom  ?obligation .
  ?obligation gist:triggeredBy ?Purchase .
  ?Purchase gist:basedOn ?offer.
  ?offer gist:isAbout ?resource .
  ?resource rdf:type gist:SourceMagnitude ;
               gist:decimalValue ?decimalValue1;
               gist:hasFixedUoM acc:_USDollar ;
               rdfs:label  ?label1.
 acc:_Euro acc:convertToUSDollar ?ConversionRate.
 acc:_Euro acc:commissionToBase ?CommissionRate.
}

The result is:

?Net_Income (in €uro)

"1.86E0"

Note

The displayed result "NET INCOME" is obtained by subtracting the bought price (in €uros) by the client from the converted price that is equivalent to $100USD.

2.4.1 Requirement

Read more about the "requirement" class in gist enterprise ontology.

2.4.2 Person

Note: an employee is considered and inferred to be a resource and a legal entity.

2.4.3 Organization

A legal entity is any Entity that is an association, corporation, partnership, proprietorship, trust, or individual that has legal standing in the eyes of law.

As you know;

'The amount of unstructured data in enterprises is growing significantly.'

Therefore, the bellow classes describe the data that are related to all the accounting parts of a company and all the documents that are produced from them.

3.1 Deliverable

In the financial World, we are considering financial statements as deliverables. Thus, the gist:Deliverable class is the actual upper class of: Report, Statement, Financial Statement. (See the full diagram)

3.2 Scope

In this context, a scope defines the accessibility of something.

Note

It is equivalent to:

gist:Collection and ( gist:hasMember some LegalEntity )

3.3 Magnitude

The gist:SourceMagnitudeclass defines all the raw data that are not the result of any calculation.

The gist:DerivedMagnitudeclass defines any data resulting from a calculation on a set of SourceMagnitude.

Note

A derived magnitude is equivalent to:

gist:Magnitude

and ( gist:derivedFrom some gist:Magnitude )

and ( gist:hasDerivation some gist:Derivation )

3.4 Report

A report is a document that presents information in an organized format for a specific audience and purpose. (See the full diagram)

Note

A report is equivalent to:

gist:Deliverable

and ( gist:availableTo some gist:Scope )

and ( gist:basedOn some gist:Template )

3.5 Statement

A statement is an official or approved report. (See the full diagram)

Note

It is a direct sublass of the previously mentionned gist:report class. Then it inherites the same equivalence definition than a report, namely:

gist:Deliverable

and ( gist:availableTo some gist:Scope )

and ( gist:basedOn some gist:Template )

3.6 Financial Statement

A financial statement is a specific statement that is related to the accounting or financial part of a company. (See the full diagram)

It is equivalent to:

gist:Statement

and ( gist:actualEnd some gist:TimeInstant )

and ( gist:actualStart some gist:TimeInstant )

and ( gist:contains some gist:Magnitude )

Note

Just like any statement, a financial statement inherites the same equivalence definition than a report, namely:

gist:Deliverable

and ( gist:availableTo some gist:Scope )

and ( gist:basedOn some gist:Template )

A transaction triggers a financial recognition.

4.1 Financial recognition

A financial recognition acknowledges the Enterprise's Financial Statements. It conforms to the gist:Requirement class. A financial recognition is triggered by a transaction that produces new derived magnitudes.

It is represented by the gist:FinancialRecognition class, that is equivalent to:

gist:Collection

and ( gist:affects some gist:DerivedMagnitude )

and ( gist:basedOn some gist:Template )

and ( gist:conformsTo some gist:Requirement )

and ( gist:hasMember some gist:Transaction )

and ( gist:produces some gist:DerivedMagnitude )

and ( gist:triggeredBy some gist:Transaction )

5.1 Income Statement

An income statement is one of the three (along with balance sheet and statement of cash flows) major financial statements that reports a company's financial performance over a specific accounting period.

Net Income = (Total Revenue + Gains) – (Total Expenses + Losses)

5.2 Balance Sheet

A balance sheet is a financial statement that reports a company's assets, liabilities and shareholders' equity at a specific point in time.

Assets = Liabilities + Shareholders’ Equity

5.3 Cash Flow

Cash flow is the net amount of cash and cash-equivalents being transferred into and out of a business.

Free Cash Flow = Operating Cash Flow - Capital Expenditures

5.4 Financial Statements

Financial statements are written records that convey the business activities and the financial performance of a company. Financial statements are often audited by government agencies, accountants, firms, etc. to ensure accuracy and for tax, financing, or investing purposes.

5.5 Debits and Credits

An increase in liabilities or shareholders' equity is a credit to the account, notated as "CR."

A decrease in liabilities is a debit, notated as "DR."

Using the double-entry method, bookkeepers enter each debit and credit in two places on a company's balance sheet.

5.6 Adjusting Entries

Adjusting journal entries are used to record transactions that have occurred but have not yet been appropriately recorded in accordance with the accrual method of accounting.

Adjusting journal entries are recorded in a company's general ledger at the end of an accounting period to abide by the matching and revenue recognition principles.

The most common types of adjusting journal entries are accruals, deferrals, and estimates.

5.7 Liquidity

Liquidity refers to the ease with which an asset, or security, can be converted into ready cash without affecting its market price.

5.8 Payroll Accounting

Payroll is the total of all compensation a business must pay to its employees for a set period of time or on a given date. Companies must also perform accounting functions to record payroll, taxes withheld, bonuses, overtime pay, sick time, and vacation pay ...

6.1 Working Capital and Liquidity

Jumping right in financial concepts;
As you may know, the "Working Capital Ratio" represents a company's ability to pay its current liabilities with its current assets.

3 possibilities

Working Capital < 1

Working Capital = 1

Working Capital > 1

4.2 Solvency

The solvency ratio is calculated by dividing a company's after-tax net operating income by its total debt obligations. The net after-tax income is derived by adding non-cash expenses, such as depreciation and amortization, back to net income. these figures come from the company's income statement. Short-term and long-term liabilities are found on the company's balance sheet.

Solvency Ratio= (Short-Term Liabilities + Long-Term Liabilities) / (Net After−Tax Income + Non-Cash Expenses)

4.3 Operating Efficiency

Operational efficiency is a measure of how much costs are incurred during a given economic or financial activity, where lower costs equals greater efficiency.

For investors and traders, markets exhibit operational efficiency when transaction costs are low.

Offering bulk discounts or free commissions to traders is one way to increase the operational efficiency of investment markets.

4.4 Profitability

Profitability ratios are a class of financial metrics that are used to assess a business's ability to generate earnings relative to its revenue, operating costs, balance sheet assets, and shareholders' equity over time, using data from a specific point in time.

Enterprise Ontology
for the Financial World

1. Basic SPARQL queries

Prepping

1.1.1 The first step

1.2.1 Assign the magnitudes

1.2.2 A query for magnitudes

1.2.3 Available conversions

1.3.1 Commission rate

1.3.2 Buy / Sell

2. The Knowledge Graph

2.1.1 Offer

Act I (scene 1)

Act I (scene 2)

Act I (scene 3)

2.1.2 Purchase

Act II (scene 1)

Act II (scene 2)

Act II (scene 3)

Act II (scene 4)

2.1.3 Movement

2.1.4 Transfer

Act II (scene 5)

2.1.5 Allocation

Act II (scene 6)

Act III (scene 1)

2.2.1 Obligation to deliver

2.2.2 Obligation to pay

Act III (scene 2)

2.3.1 Ownership

2.3.2 Possession

Act IV (scene 1)

2.4.1 Requirement

2.4.2 Person

2.4.3 Organization

3. A deeper dive

4. A Transaction

5. Enterprise Accounting

6. Accounting RATIOS

Enterprise Ontology for the Financial World

1. Basic SPARQL queries

Prepping

1.1.1 The first step

1.2.1 Assign the magnitudes

1.2.2 A query for magnitudes

1.2.3 Available conversions

1.3.1 Commission rate

1.3.2 Buy / Sell

2. The Knowledge Graph

2.1.1 Offer

Act I (scene 1)

Act I (scene 2)

Act I (scene 3)

2.1.2 Purchase

Act II (scene 1)

Act II (scene 2)

Act II (scene 3)

Act II (scene 4)

2.1.3 Movement

2.1.4 Transfer

Act II (scene 5)

2.1.5 Allocation

Act II (scene 6)

Act III (scene 1)

2.2.1 Obligation to deliver

2.2.2 Obligation to pay

Act III (scene 2)

2.3.1 Ownership

2.3.2 Possession

Act IV (scene 1)

2.4.1 Requirement

2.4.2 Person

2.4.3 Organization

3. A deeper dive

4. A Transaction

5. Enterprise Accounting

6. Accounting RATIOS

Enterprise Ontology
for the Financial World