I am comparing taxonomy_xml_formats() in 6.x-2.x-dev and 6.x-1.3 . In 1.3, the function just parses the filenames, but in 2.x-dev it include()s all the files and does a basic check.

This causes a function naming collision between rdf_format.inc and leobard's skos_format.inc (which we need to include). They both define taxonomy_xml_get_literal_string() . I would suggest copying the 1.3 version of taxonomy_xml_formats() into the 2.x branch because doing the function exists check doesn't guarantee that the .inc is usable and has the disadvantage of loading lots of files that aren't needed.

Alternatively, we could pull out the common functions for RDF and SKOS and put them in a common include file or rename the functions in the SKOS file.

I am happy to submit a patch, just tell me which way to go.

Comments

kenorb’s picture

+1

dman’s picture

The relevant addition in the contributed SKOS format example was folded in within a week of the contrib.
SKOS is just a subset of RDF. SKOS is RDF.

This means that the RDF parser should be doing the job it was intended to do - consuming SKOS. rdf_format reads SKOS.

I picked the useful fruit off the tree (it was internal support for bnodes) and moved on. It was really good!
The SKOS vocabulary (the labels SKOS uses) has been supported as part of the RDF format since the early days. The contrib #560326: RDF export/import should be W3C standard SKOS - here is the patch ONLY added bnode support which is an XML/RDF parser syntax thing, and relevant to the ways that some producers create their files.

What happened was that leobard found a SKOS file that used bnodes and found it neccessary to add bnode support to read that particular SKOS.
He didn't add SKOS support - it was always there. He added bnode support.
Some SKOS files that didn't use bnodes were already, and are, readable by the module.
That contribution was useful, because by folding it in, the rdf_format can now also read other RDF (like the W3C examples) whether they choose to use bnode notation or not.

Now that I've made that entirely clear - it's entirely possible that there are 'SKOS' files out there that don't import right. :-) This is probably nothing to do with them being SKOS or non-SKOS, it is probably to do with them being RDF that uses a specific notation that has not yet been encountered,
The actual problem may be that it's the RDF that doesn't import right or parses in an unexpected way. And if that is the case, then there may still be improvements to make.

But there should be - according to the code anyway - no reason why the same file would successfully import by the contrib skos_format but fail in the more generic rdf_format importer. If that is really happening, I'd like to see an example of such a file.

carinadigital’s picture

Status: Active » Closed (fixed)

Yes. You're right. I've imported skos file using the RDF import procedure using the dev release.