The eProcurement Ontology provides the formal, semantic foundation for the creation and reuse of linked open data in the domain of public procurement in the EU.
European Union Public License 1.2
58
stars
18
forks
source link
consider using W3C CUBE patterns for representing counts #407
epo:SubmissionStatisticalInformation has a gazillion overly-specific props like epo:hasReceivedMicroTenders, epo:hasReceivedSMETenders etc.
There are a couple of problems with this approach:
to add a new count, you need a new prop, thus new version of the ontology
you can't relate to other counts, eg "how many SME have passed the first phase of a multi-phase procedure" or "how many SME have won specific tasks through the duration of a framework contract"
you can't easily relate to non-count characteristics, eg epo:isSMESuitable, to answer questions like "for procedures specially suited to companies in category X, what proportion of tenders were from companies in that category?"
naming problems, eg epo:hasReceivedMicroTenders really should be numberOfTendersReceivedFromMicroEnterprises:
I was puzzled "what are micro tenders? Too few pages? Too low price?" (I'm not lying)
"has" is ambiguous between a boolean and an integer
Consider a pattern like this (where appliesTo is a CUBE dimension, and value is a CUBE measure):
<stats> a Dataset;
<obs1> inDataset <stats>; appliesTo <companyKind/Micro>; value 10.
<obs2> inDataset <stats>; appliesTo <companyKind/SME>; value 5.
To add more dimension items, you just add to the nomenclature, don't need to add another prop appliesTo.
You can easily add more measures, eg
<stats> a Dataset;
<obs1> inDataset <stats>; appliesTo <companyKind/Micro>; received 10; won 0.
<obs2> inDataset <stats>; appliesTo <companyKind/SME>; received 5; won 2.
Or you can add more dimensions for a wordier, but more modular approach eg:
<stats> a Dataset;
<obs1> inDataset <stats>; appliesTo <companyKind/Micro>; measures <tenderDimension/received>; value 10.
<obs2> inDataset <stats>; appliesTo <companyKind/SME>; measures <tenderDimension/received>; value 5.
# <obs3> inDataset <stats>; appliesTo <companyKind/Micro>; measures <tenderDimension/won>; value 0.
<obs4> inDataset <stats>; appliesTo <companyKind/SME>; measures <tenderDimension/won>; value 2.
<obs3> is not needed because this approach supports SPARSE representation: missing is better than 0.
(I didn't bother to check whether qb:Dataset and qb:inDataset are really named that way).
There's a very wide body of work using CUBE, specialized viewers, etc.
epo:SubmissionStatisticalInformation
has a gazillion overly-specific props likeepo:hasReceivedMicroTenders, epo:hasReceivedSMETenders
etc.There are a couple of problems with this approach:
epo:isSMESuitable
, to answer questions like "for procedures specially suited to companies in category X, what proportion of tenders were from companies in that category?"epo:hasReceivedMicroTenders
really should benumberOfTendersReceivedFromMicroEnterprises
:So instead of the current:
Consider a pattern like this (where
appliesTo
is a CUBE dimension, andvalue
is a CUBE measure):To add more dimension items, you just add to the nomenclature, don't need to add another prop
appliesTo
.You can easily add more measures, eg
Or you can add more dimensions for a wordier, but more modular approach eg:
<obs3>
is not needed because this approach supports SPARSE representation: missing is better than0
.(I didn't bother to check whether
qb:Dataset
andqb:inDataset
are really named that way). There's a very wide body of work using CUBE, specialized viewers, etc.