Openrefine: Error on First Use of a Facet

[scottythered]

version: OpenRefine 3.0
OS: Windows 7E
Browser: Chrome
Java: jre1.8.0_66

I'm seeing the terminal post an error with v3.0. It happens whenever I start a new project -- I can edit cells, move columns, etc, but the first time I try to create a facet, I get the above error and the "Working" screen keeps turning over. If I reload the browser page and try the facet again, it works. It seems to affect all facet types, but only the first time one is created.

Checked on Linux version 3.0, and not seeing the same behavior.

[thadguidry]

This looks like its an issue in the DERI RDF extension version you are using.
This might be easily fixed if you use the newest version under here ? https://github.com/stkenny/grefine-rdf-extension/releases

Correct @stkenny ?

[scottythered]

Ah! I had no idea there was a new version. I was under the impression that the RDF extension had been abandoned?

[thadguidry]

You can see the semi-complete list of extensions on our Downloads page and scroll down (notice we have both versions of RDF extension) http://openrefine.org/download.html#list-of-extensions

[jackyq2015]

I am wondering if there is a good practice to maintain the interface between the core and plugin in a way that can allow the core part change without breaking plugin. Or Openrefine's plugin mechanism is too rigid to extend.

[thadguidry]

@jackyq2015 I don't see why not...that was the whole idea of the command/operations partitioning that David did...I further recall that plugins would be able to use and extend operations... that would be done through the AbstractOperations ?? and the idea was simple in practical terms... core + op https://github.com/OpenRefine/OpenRefine/blob/master/main/src/com/google/refine/operations/OperationRegistry.java#L74

Question is: if it is abstracted enough, and can even create/use custom metadata during a plugin's abstracted operations ?
2nd Question: Do we allow plugins to customize the Engine as well as the Model ? I think they can and can provide Engine config, yes?

[wetneb]

@jackyq2015 as far as I can tell, the main reason for incompatibilities is the use of ant as build system, because this introduces duplicate and conflicting jars of common dependencies. So the migration to Maven will ease that (but of course the migration to Maven will break all extensions initially by doing so).

The good practices to avoid incompatibilities are pretty much the same as for any other software component: exposing stable interfaces (which haven't changed much for the last few years) and keeping the same libraries. (That is exactly the opposite of the move to Jackson but hey…)

@thadguidry yes extensions can have arbitrary metadata on their operations; no, they cannot configure the engine (facets cannot be extended in a clean way currently). The interaction with the model is limited to the creation of overlay models.

So the extension points currently are:

• commands;
• operations (and therefore changes);
• overlay models;
• preference states;
• arbitrary front-end changes.

So the back-end is pretty clean in terms of extension points.

[ostephens]

In another piece of s/w I’ve written extensions for the extension was required to state a version compatibility which would be used by the main s/w to decide whether to load the extension or not.

Would this be an approach we could take with OR?

[wetneb]

@ostephens sure, that would make sense, but that would probably require tweaking Butterfly, I think.
Rather than trying to fix this obsolete and unmaintained library I would prefer migrating to something standard like Spring.

[jackyq2015]

@wetneb I don't think the build system is the root cause of the current situation. But migrating to maven may help to expose the problem at early stage. Basically, it boil down to the same idea @ostephens propose: the version control. One is from the build system, another is from code level though.

[wetneb]

Closing this as the issue is about the RDF extension.