[ECODP-dev] Package failing to import [release 09]

Tue Sep 3 13:40:07 UTC 2013

Hi Bert,

a) I would have to investigate this further and get back to you, but the
problem occurs when parsing the RDF XML data that is submitted in the
dataset JSON via the API. However it seems surprising that this not come up
when you tested your rdf2ckan application prior to the release being
finalised. Are there any differences between the type of RDF data that the
PO is submitting and the RDF test data that you used with rdf2ckan? This
would help to narrow it down.

b) As mentioned in my previous email, a simple workaround for this issue is
to just not include the license_id field in the JSON that you send to CKAN
if you do not have a license. In the example JSON that Dimitrios included
you are sending license_id: [].

Regards,
John

On 3 September 2013 13:38, Bert Van Nuffelen <bert.van.nuffelen at tenforce.com
> wrote:

> Hi John,
>
> What are the business changes we have to ensure it gets uploaded in the
> release 00.09.0x which has these bugs?
>
> * for a) which characters to avoid?
> * for b) adding a license
>
> kind regards,
>
> Bert
>
>
>
> 2013/9/3 John Glover <john.glover at okfn.org>
>
>> Hi Dimitrios,
>>
>> These logs are a bit confusing as they come from different requests. The
>> file '2013-09-02_odpfrontend_httpd_ecodp_error.log' has an error from 11:54
>> on 2013-09-02, but the 'odp_ckan_errors.txt' file contains errors from this
>> morning. These actually refer to two separate bugs that have since been
>> fixed in the latest ckanext-ecportal.
>>
>> The error in '2013-09-02_odpfrontend_httpd_ecodp_error.log' is the same
>> as the problem that you reported in the email thread 'Import SG package
>> problem', and is a bug with string encoding in ckanext-ecportal. I'm not
>> sure that there is anything that can be done to fix this on the PO side
>> without updating the extension.
>>
>> The errors in odp_ckan_errors.txt file are from a validation bug in
>> ckanext-ecportal as it is expecting to find a license_id that is either a
>> string or a list of strings, and instead you are passing it an empty list
>> (as you can see in odp_regExp.json). This was discussed in the email thread
>> 'no license causes python exception'. This problem is now fixed, but as a
>> short-term workaround this validation should pass if you remove the field
>> entirely when the license is not available.
>>
>> Regards,
>> John
>>
>>
>> On 3 September 2013 10:17, Dimitrios Mexis <dimitrios.mexis at tenforce.com>wrote:
>>
>>>  Hello John/David,
>>>
>>> PO tries to import sg.zip package which contains regExp.rdf
>>>
>>> The json attached is from ODP. and the relevant copy of the log file.
>>> For me, the json fails to be imported and I don't understand the cause.
>>>
>>> The files with dates, are the output from PO as given.
>>>
>>>
>>> Regards
>>> Dimitrios
>>>
>>
>>
>> _______________________________________________
>> Ecodp-dev mailing list
>> Ecodp-dev at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/ecodp-dev
>>
>>
>
>
> --
> Bert Van Nuffelen
>
> Semantic Technologies Software Architect at TenForce
> www.tenforce.be
>
> Bert.Van.Nuffelen at tenforce.com
> Office: +32 (0)16 31 48 60
> Mobile:+32 479 06 24 26
> skype: bert.van.nuffelen
>
> _______________________________________________
> Ecodp-dev mailing list
> Ecodp-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ecodp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.okfn.org/mailman/private/ecodp-dev/attachments/20130903/91ffa29f/attachment.html>