[pd-discuss] Using an intermediate language for pdcalc proposal

[Rufus Pollock]

On 10 March 2011 15:17, Platonides <platonides at gmail.com> wrote:
> Rufus Pollock wrote:
>> The basic issue IMO is that a) you need a fully expressive schema
>> language b) you have to translate that schema into code. By the time
>> you've got a schema that is expressive enough and translators you may
>> as well have just used code -- your schema will need conditionals,
>> loops etc and so it will start looking a lot like a programming
>> language in which case so why not just use a proper one in the first
>> place ...
>
> Loops is precisely something that I don't think you would need for this.

What about multiple authors?

for author in work.authors: check_life_plus_70(author)

> Also, the intermediate could make sense taken as natural language, so
> that it could be presented to experts/lawyers

I don't think there is a disagreement here. From the very start we
have all been working to prepare flow charts. This debate is whether
one attempts to convert these flow charts to some intermediate
'flow-chart' xml language that is in turn converted to calculator code
in an app or whether you convert those flow charts directly to code.
I'm advocating the latter :)

Rufus

>
> Maarten Zeinstra wrote:
>> The question at every node of the available trees fall in three categories:
>> 1. Is X of type Y?
>> 2. Is X (larger/smaller) than Y?
>> 3. Is X-Y (larger/smaller) than Y?
>
> I'm surprised that it can be simplified so much.

So am I.

>> The open source public domain calculator that Europeana is developing uses an intermediary XML file to store calculators.
> I wouldn't have used XML for this, but if something is already using it,
> it makes sense to use the same format.
>
>>  I have been looking to push this software to mediawiki, if you would like to collaborate with me...

It would easy to do a a php port of the python calculators and we'd
love to have php versions in the pdcalc library (we're not python
chauvinists!).

I really think it is going to be less work (at least in a first pass)
to just implement in a simple code algorithm (perhaps with inheritance
to deal with lots of similar stuff in different jurisdictions).

Here's an example algorithm:

<https://bitbucket.org/okfn/pdcalc/src/a426b88082cf/pdcalc/pd/ca.py>

Rufus