taverna-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <st...@apache.org>
Subject RE: Advanced Report Reminder for December 2018
Date Wed, 21 Nov 2018 08:21:35 GMT
On Tue, 13 Nov 2018 13:46:00 +0000, Ian Dunlop <ianwdunlop@gmail.com> 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

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.


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

View raw message