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

Thu Mar 17 10:53:20 UTC 2011

I believe that is exactly the debate. 

We both agree that law scholars should not write code. However should programmers be responsible encoding the decisions that the law scholars indicate? I believe they should not, you believe they should. 

This works really well when the law scholars use a flowchart making tool and a parser is written for those developed files.

Europeana's calculator does this using the free flowchart making tool yEd and parse one of the available formats (.GraphML). That way the coders never need to touch the actual decision making structure itself, reducing the change of errors. 

On Mar 17, 2011, at 11:46 , Rufus Pollock wrote:

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

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