Add skos lookup (#415)

[dr0i]

Works like fix function 'lookup, also using a Map. The Map is build dynamically
querying an RDF model.

See metafacture/metafacture-core#415.

[TobiasNx]

Could you add a short documentation of the function, so that I know how to use/test it and write integration tests for it?
https://github.com/metafacture/metafacture-fix#functions

[blackwinter]

The issue reference #415 is wrong, it should be metafacture/metafacture-core#415 (also in the commit message).

[dr0i]

The issue reference #415 is wrong, it should be metafacture/metafacture-core#415 (also in the commit message).

thx - fixed that

[dr0i]

@TobiasNx You use the rdf-lookup like this:

set_field("notation", "https://w3id.org/kim/hochschulfaechersystematik/n4")
lookup_rdf(notation, https://raw.githubusercontent.com/metafacture/metafacture-fix/7b29be   82d78d8b1959b6ee7cb93722036e897162/metafix/src/test/resources/org/metafacture/metafix/maps/test.ttl,  target:"skos:notation")

(explanation: the output field is notation, so we shall have it in the data. The value of this field is substituted by the value of the Property skos:notation of the Subject https://w3id.org/kim/hochschulfaechersystematik/n4).
It's geared to the known lookup method.

See also the 4 tests at

metafacture-fix/metafix/src/test/java/org/metafacture/metafix/MetafixLookupTest.java

Line 740 in b6d394f

@Test

.

[dr0i]

Did a git pull --no-ff origin master and resolved the conflict.

[blackwinter]

Did a git pull --no-ff origin master and resolved the conflict.

I would've preferred a rebase, but that's just me I guess... ;)

[dr0i]

I would've preferred a rebase, but that's just me I guess... ;)

No, I think you are right. Rebased and force-pushed.

[dr0i]

You may want to have a look at it again @blackwinter .
be3fbaf is just a bugfix.
Last commit fd795f9 introduces "following redirects", which is not supported "out-of-the-box" by jena 3.17.0 (the last one compatible with java 8). Note the @Deprecated annotation. The lookup of the URL is also part of the test (shouldLookupRdfUrlWithRedirection), but I don't like to be so much dependent on external resources when building - how do you handle this? Just remove the test?

[blackwinter]

I haven't really looked at the implementation yet. This was only superficial so far.

Are you saying it's ready for review now?

[dr0i]

Are you saying it's ready for review now?

Yes, just removed the draft status of this PR to make that clear.

[blackwinter]

As a general remark: It would be nice if the branch matched the pull request status; i.e., removing the WIP prefix and possibly squashing/rebasing the preliminary work.

[dr0i]

You could use WireMock, like we did for HttpOpener.

Did this in 253e25c. Note that I deliberately didn't use @WireMockTest because that resets the stub every time a new wiremock test is executed , while I want to reuse that stub. Also I don't use WireMockRule because @Rule don't allow to have static fields.

[blackwinter]

Re SLF4J: fixed in c9a4cb7.

There are still (new) issues after 62da8a0 (previously c9a4cb7):

MetafixLookupTest STANDARD_ERROR
    SLF4J: Class path contains multiple SLF4J bindings.
    SLF4J: Found binding in [jar:file:.../.gradle/caches/modules-2/files-2.1/org.slf4j/slf4j-log4j12/1.7.21/7238b064d1aba20da2ac03217d700d91e02460fa/slf4j-log4j12-1.7.21.jar!/org/slf4j/impl/StaticLoggerBinder.class]
    SLF4J: Found binding in [jar:file:.../.gradle/caches/modules-2/files-2.1/org.slf4j/slf4j-simple/1.7.21/be4b3c560a37e69b6c58278116740db28832232c/slf4j-simple-1.7.21.jar!/org/slf4j/impl/StaticLoggerBinder.class]
    SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
    SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]

[blackwinter]

There are still (new) issues after 62da8a0 (previously c9a4cb7):

Resolved with 3c09175¹. Ready to merge.

Footnotes

1. The reason for :metafix:generateXtextLanguage seemingly requiring an implementation dependency on SLF4J now is still unclear. ↩

[dr0i]

Thx a lot @blackwinter !