VIVO-281: Consider whether extended linked data can/should be made optional in configuring a VIVO installation

[chenejac]

Jon Corson-Rikert (Migrated from VIVO-281) said:

Mike Conlon commented at the conference that VIVO's linked data returns much more data than he thinks is necessary for a linked data request, affecting performance. This has been done consciously (see https://issues.library.cornell.edu/browse/NIHVIVO-3152, https://issues.library.cornell.edu/browse/NIHVIVO-3601), based on early feedback suggesting that limiting the number of requests needed to obtain a useful response, but it would be helpful to be able to state what we do, whether the "extended" aspect is configurable, and whether we think it should or should not be configurable. Unless trivial to implement any changes would have to be planned for a future release.

[chenejac]

Jim Blake said:

There was some question about whether we would disable this completely, or make it a startup option, or make it a request option.

We already allow the request to specify include="address" or several other categories of information. Each such category is associated with SPARQL queries that are used to augment the RDF that will be returned.

So perhaps we want to make this just another option on the request?

[chenejac]

Jon Corson-Rikert said:

Making extended linked data a request parameter (with the default being set to off) seems like a good approach for v1.6, with the option of removing for the following release.

Ideally this would not just be another "include=address" option but a separate "extended=true" parameter, as the former belongs to Stella's rich export functionality and this is handled elsewhere, even if written by Stella.

[chenejac]

Jim Blake said:

This change will not be difficult to accomplish -- the difficult part will be the decisions:

1) What to do? I agree with the "extended=true".

I wonder how we should document this option, since it is not part of the Linked Open Data protocol. I also don't see where the rich export option is documented.

2) What is non-extended LOD? This tutorial offers some guidelines: http://wifo5-03.informatik.uni-mannheim.de/bizer/pub/LinkedDataTutorial/#deref

It suggests: a) all triples that have the URI as either subject or object. That's clear enough. b) "any additional information about related resources that may be of interest in typical usage scenarios." How do we interpret that? One option would be to include the labels and types of any related objects, and if the related objects are context nodes, to include the URIs, labels, and types of the object on the "other side" of the context node. c) "each RDF document should contain a license under which the content can be used". Any thoughts on this?

3) How to accomplish the transition? In order to not break any sites that are currently relying on the extended LOD, I would create a runtime option that would change the default to "extended=true". As we had discussed, this option might be deprecated so future releases would always default to "extended=false".

[chenejac]

Jim Blake said:

After inspecting the code and talking with Brian Lowe, it appears that the current implementation exports more data than was intended. It's possible that simply fixing the code to accomplish its original intention would suit us.

OK, that's not true. I simply misunderstood the code.

[chenejac]

Jim Blake said:

After release 1.6, remove the Extended LOD code.

[chenejac]

Jon Corson-Rikert said:

Include language from the Terms of Use -- "To the extent copyrightable, the information presented on the VIVO website and available as Resource Description Framework (RDF) data from VIVO at __ is intended for public use and is freely distributed under the terms of the Creative Commons CC-BY 3.0 license which allows you to copy, distribute, display and make derivatives of this information provided you give credit to ____. Any non-copyrightable information is available to you under a CC0 waiver."

This is populated with a substitution but I'm not sure from where.

[chenejac]

This issue is related to #289 This issue is related to #290