Pilot 3 mapping: Prices

[Polymathronic]

The pilot 3 mapping spreadsheet has contract_initial_value_cost_eur mapped to both pc:actualPrice and pc:estimatedPrice. Is this just a mistake in the spreadsheet or also in your ETL pipeline?

[mogaio]

the spreadsheet is not updated ... we will update it once we finalize the pipeline

[vafopoulos]

If you do not updated, we cannot make proposals or review

[mogaio]

The spreadsheet is now updated and shared with you, you can access it from this url:
https://docs.google.com/spreadsheets/u/1/d/1_Cw8HtrBH8Jlhw_6MNdTrV4SeaT-ixyWhaiSc4zdMSg/edit?usp=drive_web

[Polymathronic]

Shouldn't the 'Resource' show the resources an object property points to? An RDF snippet demonstrating the usage of the property would also make sense. It's currently showing the URLs of the properties (and not even all of them), which is redundant, as those can be inferred based on the prefixes.

[Polymathronic]

Also, the description of contract_contract_value_cost_eur seems to be suggesting that it should be mapped to pc:agreedPrice, rather than pc:actualPrice:

After a tender is awarded a Contract, a price is agreed between the awarded supplier and the contracting authority. This property assigns that price to the Contract.

pc:actualPrice is the "actual price after contract realization".

[giorgosvaf]

I think you should check your mapping again.

Please check the following comments,

1. You don't need to map gr:hasCurrencyValue to contract_contract_value_cost_eur or to contract_initial_value_cost because gr:hasCurrencyValue is used for the amount in general.
   For instance you have to map contract_contract_value_cost_eur to pc:agreedPrice or whichever is the correct mapping just like you did in pc:documentsPrice case.
2. I don't see anywhere in the document the property pc:agreedPrice
3. I see that you use both pc:agreedPrice and pc:estimatedPrice for a specific instance of pc:Contract which conceptually is wrong, because that way you can not specify that you are describing different kinds of contacts, if you consider that you start from the same resource in both cases.

Query,

select distinct * 
from <http://yourdatastories.eu/pilot3> 
where {
<http://linkedeconomy.org/resource/Contract/800377> ?p ?o
} 

[Polymathronic]

Do these bits of information (estimated and agreed price) refer to, essentially, different concepts? Seeing the original data source could help, I guess.

[giorgosvaf]

Depending on your data please explain why you use estimated and agreed price based on examples(correct mapping and short comment why you use it).

Then also explain why you use estimated and agreed price on the same contract resource and why you use different approach from pilot 1 where each contract has one of the above prices in order to specify the different phase of individual contracts.

[LUKPOR]

We believe (based on our data) that contract_initial_value_cost_eur should be mapped to pc:estimatedPrice and contract_contract_value_cost_eur should be mapped to pc:agreedPrice. We believe pc:actualPrice should be omitted. It is reasonable to say that whenever there is a contract, first the estimated price is given (initial value) then it is negotiated and approved - agreed price. The actual price which is the actual cost (or the actual claim made against the contractual, agreed price) is most probably not considered in that dataset, especially that many of the projects are ongoing projects (therefore, it is impossible to have the exact amount claimed). Therefore, it makes perfect sense to keep both estimated and agreed price for the same contract and the actual price can be left out. In fact, the actual price goes beyond the contract - more explanation in the email.

[giorgosvaf]

1. As far i see the mapping seems to be right.
2. About contract resource and prices issue, this approach does make sense but you have to consider the following,
   If you have for the same resource both estimated and agreed price, you will not be able to know the phase that the contract belongs to(contract or tender phase).
   For example, tender phase (estimated price) is not supposed to have any seller(if added) but contract phase(agreed price) could have, so if you have the same URI and link the resource to the seller, you will have a URI which will point to different entities actually(tender & contract phase) and you will not be able to know in which phase the seller was linked to.

A Possible solution on this would be the following,
estimated Price:
http://linkedeconomy.org/resource/Contract/Tender/1302039 pc:estimatedPrice ...
agreed Price:
http://linkedeconomy.org/resource/Contract/Contract/1302039 pc:agreedPrice ...

If you follow what you have now, it's not impossible to have internal model issues in the future.
We will expect your comments and your implementation in order to move forward.

Hope that helps.

[Polymathronic]

Since you already have the concept of a tender, that would essentially mean you would just have to attach the estimated prices to tenders, instead of contracts. Right George?

[giorgosvaf]

I meant, the tender phase of a contract, not the pc:Tender class.

pc:agreedPrice & pc:estimatedPrice must have pc:Contract as domain class.

[Polymathronic]

OK. @mogaio please follow the pilot 1 approach.