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

[Rufus Pollock]

On 17 March 2011 09:34, Maarten Zeinstra <mz at kl.nl> wrote:
> 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.

That isn't the debate :) We also agree we want to develop flow charts
/ questionnaires for the legal experts (as we did at the original
workshop 1.5y ago) :)

The debate is about how those flow charts / questionnaires get
translated into runnable code :)

> 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.

We are already decoupling the two sides -- see above. The real
question, as I see it, is how do you get from the human-produced (and
human-readable) flow charts to code. I'm not convinced that an
intermediate xml pd algorithm language helps ;)

However I should emphasize we are *not* debating the question of
whether law scholars should answer questions / draw flowcharts rather
than write code -- that is agreed they don't write code :)

Rufus

> 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/
>
>
>



-- 
Co-Founder, Open Knowledge Foundation
Promoting Open Knowledge in a Digital Age
http://www.okfn.org/ - http://blog.okfn.org/