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


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
  • 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
      {?Magnitude1 rdf:type gist:SourceMagnitude;
                   gist:decimalValue ?decimalValue1;
                   gist:hasFixedUoM acc:_USDollar;
                   rdfs:label ?label1.}
      {?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)
      {?Magnitude1 rdf:type gist:SourceMagnitude;
                   gist:decimalValue ?decimalValue1;
                   gist:hasFixedUoM acc:_USDollar;
                   rdfs:label ?label1.
      acc:_Euro acc:convertToUSDollar ?ConversionRate.}
      {?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

  • 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)
      ?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)
      ?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.'

    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
    ?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 ,
      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 ,
    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 ,
    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:
  • 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 ,

    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
      acc:_Currency_Exchange_Agency_URI gist:owns ?BankAccount .
      ?BankAccount rdf:type acc:GuaranteedBankAccount .
      ?BankAccount gist:hasMagnitude ?magnitude .
      ?magnitude gist:decimalValue ?Amount1 .
      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

  • 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
        ?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
          ?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)
      ?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)
  • 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:

    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:

    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:

    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:

    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:

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

    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:

    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.

    Semantic Logo