On Tue, 13 Nov 2018 13:46:00 +0000, Ian Dunlop <[email protected]> wrote: > Eg Tavmob#68 looked like it was ready to merge but Sagar wanted the > committer to use RxJava/Retrofit patterns in it. I probably wouldn’t > mind so much.
Agreed that the pattern should not be too important. Sagar, can we merge #68 as-is? > #93 looks like there is a library missing so it failed to build in > travis. I saw you closed this :) > “Although our use of Creative Commons should be allowed by Legal's > resolved FAQ, we recognize that IPMC feelings are otherwise, so we'll > have to recode to avoid including these schema files.” > > It’s not clear to me what the approach should be. Are you saying that > legal think it is ok but the IPMC don’t? If so then shouldn’t legal > and IPMC discuss this issue and get some clarity – did this happen? >From https://www.apache.org/legal/resolved.html#category-b any CC-BY files can be used, but should be included as binaries to avoid confusion. We could maybe package the CC-BY files as *.ttl.gz to force them to be 'binaries'. I think that should still load well with Jena. However the FAQ also says: > For small amounts of source that is directly consumed by the ASF > product at runtime in source form, and for which that source is > unmodified and unlikely to be changed anyway (say, by virtue of being > specified by a standard), inclusion of appropriately labeled source is > also permitted. An example of this is the web-facesconfig_1_0.dtd, > whose inclusion is mandated by the JSR 127: JavaServer Faces > specification. For Taverna Language this is exactly the case as it is mainly Research Object and Dublin Core ontologies loaded at runtime with Jena. <https://github.com/apache/incubator-taverna-language/blob/master/taverna-robundle/src/main/java/org/apache/taverna/robundle/manifest/RDFToManifest.java> In theory it should be possible to do this code without loading the ontologies, as I don't think we use any inferencing here, rather the code is loading the properties/classes from the ontology to ensure the names are correct. But we can instead hard-code the bits from the vocbulary we use 'blind' (This would however not detect vocabulary mistakes such as dcterms:tittle ) This would mean some rewrite of RDFToManifest. > “So do you think we need to look again at that idea of putting them in > Taverna Extras on GitHub and then pull them down at build-time as Maven > dependencies?“ > Is this now the only option and if so what does it involve. Let’s just get it > done. (I’ve got the feeling I starting looking into this but got distracted > by reality). Yes, making a new Maven dependency or something that we manage outside would avoid the problem. It's perfectly fine to use CC-BY (Category B) code as a dependency. Although it may feel a bit silly to have to do this with just a few schema files that the FAQ says we can distribute, but it would make a clearer distinction between Apache-licensed code and third-party code, as with other dependencies. So we have three options: 1) Cheeky *.gz binaries in source code 2) Rewrite code to hard-code namespace and avoid dependencies 3) Package on GitHub (Taverna Extra) #1 has the risk of IPMC folks tripping again as we would still need to include CC-BY in LICENSE #2 will take a bit of developer time and makes it harder to do changes safely - but both code and ontologies are now stable #3 mean "we" (Apache Taverna community) have to maintain Maven deploys (or other kind of deploy) outside Apache so that Apache Taverna can depend on it. Again these are unlikely to change much so it's more of an one-off per schema. Before I suggested #2 but unfortunately I have not come round to try this out. Which one shall we go for? -- Stian Soiland-Reyes The University of Manchester https://www.esciencelab.org.uk/ https://orcid.org/0000-0001-9842-9718
