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

[Maarten Zeinstra]

When developing knowledge intense software, like a calculator you do not want to require legal knowledge and programming knowledge to be necessary present in one person. I've seen this time and again when researching flowcharts for Europeana together with Christina from IViR. I have a different way of thinking about these issues than Christina, Having a intermediary data model separates this layers of thinking, researching and developing.

Also maintaining a large number of jurisdiction does not depend on a software developer but a management tool. Maintenance becomes a task for the law scholar not the programmer. What you want to avoid that maintenance of the a calculator is a job for both a developer and a law scholar. That is just not efficient.

Best, 

Maarten Zeinstra

Kennisland | Knowledgeland 

T: +31.20.575.6720 | M: +31.6.43.053.919 | S: mzeinstra
www.kennisland.nl | www.knowledgeland.org

On Mar 17, 2011, at 10:14 , Rufus Pollock wrote:

> I again ask: why invent an intermediate language when we already have
> perfectly good languages and algorithms involved are complex. At least
> as a first pass why don't we just implement directly in python/php
> (using inheritance / function calls to deal with commonality). Once we
> have done, say, 5 of those which we can all look at it do we have idea
> of the kind of complexity we need to support.
> 
> Of course there is still standardization work to be done on the
> 'exchange' format for key objects (e.g. entities, works -- also on the
> wiki).
> 
> Rufus
> 
> On 17 March 2011 07:36, Maarten Zeinstra <mz at kl.nl> wrote:
>> Hi platonides,
>> 
>> I agree with you that my intermediate data format is not the most estetically pleasing of it's kind. However it is also exactly that: data. Getting Dijkstra on me is a bit of an overkill. As Dijkstra discussed algorithms, not data models. When my calculator parses this format it transforms it into a nice object oriented acyclic directed graph. I do completely agree with the evaluate property however. I think there are better solutions for that, which I didn't consider at the time.
>> 
>> Could you sketch or proof of concept a tertiary approach?
>> 
>> Cheers,
>> 
>> Maarten Zeinstra
>> 
>> Kennisland | Knowledgeland
>> T: +31.20.575.6720 | M: +31.6.43.053.919
>> www.kennisland.nl | www.knowledgeland.org
>> 
>> Op Mar 17, 2011 om 2:24 heeft Platonides <platonides at gmail.com> het volgende geschreven:
>> 
>>> Primavera De Filippi wrote:
>>>> Hi Platonides,
>>>> how is the whole thing going ? are you still interested in translating
>>>> the pdcalculators into an intermediary language?
>>>> did you get any information from Maarten? do you need any help or anything?
>>>> I think it would be nice to try and implement at least one of the
>>>> pdcalculators, as an experiment, to see how it works and whether it
>>>> could be useful.
>>>> Please keep me updated about all this !
>>>> Thanks,
>>>> Primavera
>>> 
>>> Hi Primavera,
>>> (and other list readers, too)
>>> 
>>> I originally thought that the intermediary language would just encode a
>>> fixed algorithm. However, I later talked with Maarten and he mentioned
>>> rule based systems. We both agree that they are ugly to work with (lots
>>> of and conditions). But I think that the syntax should be mapeable to a
>>> ruleset. That would allow to work with uncertainity for
>>> publicdomaincalculators usage. Or solve from a different path when
>>> missing some information.
>>> Even with a naive algorithm, that makes it more complex.
>>> 
>>> I have also looked at http://wiki.okfn.org/PublicDomainCalculators/xml
>>> format but those goto and <evaluate> are evil.
>>> 
>>> _______________________________________________
>>> pd-discuss mailing list
>>> pd-discuss at lists.okfn.org
>>> http://lists.okfn.org/mailman/listinfo/pd-discuss
>> 
>> _______________________________________________
>> pd-discuss mailing list
>> pd-discuss at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/pd-discuss
>> 
> 
> 
> 
> -- 
> Co-Founder, Open Knowledge Foundation
> Promoting Open Knowledge in a Digital Age
> http://www.okfn.org/ - http://blog.okfn.org/
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/pd-discuss/attachments/20110317/fb2d113a/attachment.html>