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

[Rufus Pollock]

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/