Can a server accept a querier's terms? - Disclaimer in the query

[rishidev]

At the moment there is a disclaimer section in the query. Can a server accept a querier's terms?

"disclaimer" : {
    "version": "<semantic version>",
    "text": "Disclaimer text...",
    "terms" : "Terms text..."
  },

[harindra-a]

hey Rishi, this is really a FYI to the server and a legal piece saying what can be done with the data. It is up to the host to decide on whether to support it.

In MME we have one from each node we pass on with the query, https://github.com/ga4gh/mme-apis/tree/master/disclaimers

we can talk about this more at next search meeting, and clarify further

[Relequestual]

I agree, a server cannot accept terms and conditions *, it's a machine. For the response, it may make sense to include a disclaimer, but I'd want to see this as a meta component rather than a root level object.

• If we use something like ADA-M it is possible we could encode consent for use. There's scope for automated discoverability of services which a given user can access. I wonder how many implementations there are of ADA-M...

---

For MME, originally there was a disclaimer, but this field was used to also express terms of use, so we ended up with two fields. The disclaimer says something about the data, the terms says something about what you agree to if you view and or use the data. I think there's scope to have both, but having terms under disclaimer doesn't make any sense to me, especially in the request.

[fschiettecatte]

Speaking for GeneMatcher, we store terms / disclaimers for each MME instance we connect to, these are both included in the match emails we send out to our submitters (along with references to use). If the remote MME instance sends us terms / disclaimers in the MME request / response, those override what is stored. I note that we also have attribution, authors, title, journal, though those last three the three components of the reference that is also included in the email.

[fschiettecatte]

How about this for the disclaimer section, I renamed it acknowledgments:

"acknowledgments" : {
    "version": "<semantic version>",
    "disclaimer": "Disclaimer text...",
    "terms" : "Terms text...",
    "reference" : "Reference text...",
  },

Updated to replace citation with acknowledgments.

[Relequestual]

I'm happier calling it acknowledgments, I feel it's more semantically correct.

references, do we mean "the way in which you must acknowledge this resource" or "here are some papers related to this resource"?

I think we should have the former, and not sure of the use of the latter (as that could be encoded in the former). I guess you could say that acknowledgment statements could be included in the terms, but it's more explicit as a separate field.

As an aside, should we specify the content of these fields? Text only? Markdown? HTML? (I feel we should avoid HTML).

We should probably open a new issue to define the fields, if we're in agreement we should have an acknowledgments component.

[Relequestual]

@rishidev:

At the moment there is a disclaimer section in the query. Can a server accept a querier's terms?

No, but the user can. In my implementation of MME, we do not show the response to the user unless they accept the terms from that service.

To my mind, a server doesn't need to accept or reject terms, as it won't, or at least shouldn't, do anything with the data without confirming with a user first.

In this instance, I've viewing a "user" as someone who is interacting with a "service" which queries Search API "servers". Not as a developer which writes code to make search requests to servers.

I acknowledge there is a use case of using such a Search API in an automated fashion say in a pipeline, however an implementor / developer should read the terms presented by each endpoint to make sure they are allowed to use the data in the way they would like.

There may need to be some "best practice" policy level document built up around this aspect.

[fschiettecatte]

Not HTML, that would create a security vulnerability, text only. I am ok with creating a new issue for this, happy to do this if you want.

[Relequestual]

Agreed, not HTML.

@fschiettecatte Feel free to create a new issue for a new component. I'm yet to formalise the process for creating components, but I have a general feeling in my head (assuming we merge and follow the format in #30 ).

[fschiettecatte]

Done, see #31

[Relequestual]

@rishidev Given you created this issue, what's required to resolve it?

[rishidev]

To clarify - The response side of the query-repsonse process wasn't what the issue was created for. So a service asking a user to agree terms and conditions before returning results is a debate for a different issue if it is needed.

As I understand it the having the disclaimer/terms etc in the request/query is making a a demand on the server that the server agrees to. On the query (i.e. what the user makes to the server) side I think the disclaimer/terms etc should be removed as it is either meaningless or potentially harmful. From comments above @Relequestual concurs with this. If we want to include it in I would like to have the Regulatory and Ethics Work Stream advise on this matter which might not fit with the schedule for finalising a version of the API.

So my suggestion is to take this out for now. If it wants to be put back in we create another issue to re-instate it, which would give us the chance to have the GA4GH Regulatory and Ethics WS advise.

GA4GH is starting to look at automated terms etc so there may well be a framework to go along side this API to handle this kind of requirement sensibly.

[Relequestual]

Thanks @rishidev

What if the "terms" were not for displaying or viewing the data, but required to accept for using the data (beyond processing by a client for those pourposes)?

@harindra-a Any thoughts on if this should remain or be removed for 0.1.0?

[rishidev]

@Relequestual The issue isn't the existence of querier imposed terms per se, but how open text querier imposed terms are accepted in a legally recognisable manner. If a server makes it clear 'we will do X,Y,Z with provided data' and a querier sends this in with 'You cannot do Y,Z with the data I provide' what happens? As it stands there if there needs to be terms they are outside the scope of this API, but I would like to pass this on to DURI or Reg & Ethics for further advice.

[harindra-a]

hi @Relequestual and @rishidev, good discussion. Definitely important long term.

I would vote we push this for post Basel/October though, for now go with how we do things in MME. I know from DURI folks, they are pretty early stage. So let's swing back to this post first release.

[Relequestual]

Oh sure, I don't feel defining this is the responsibility of this project.

I feel it makes sense to have at least something while the finer points are being worked out by other groups.

In terms of "how we do things in MME", that could work for now, in that each node must connect with each other node, but I highly expect the majority of the nodes which implement the Search API will require no authenitcation, and be discoverable, much in the same way Beacons are.

As such, the MME way of, only authed, on a node to node bases agreement, but then you have to draw up policy saying that clients must show terms of use to their users.

[harindra-a]

Yup, I meant MME way just for the approval process demo for the next few months, and maybe even phase 2 (using real data).

But long term (into next year), you are correct, the network will be a mix of open and authenticated nodes and will need specialized agreements. I think Mike Brudno brought this up last MME meeting as well. Maybe we should start a small group to investigate this as it will be a long term thing (actually MME is still ironing this out after this many years). I know few policy folks who are regulars at Search meetings, maybe they can take this on and take lead

[fschiettecatte]

I view the acknowledgments section as a convenience bucket for the transport of terms & conditions. The protocol should not define what happens with then once they are out of the pipe. As I mentioned before MME v1 has a lot of policies which repository member are required to adhere to which have nothing to do with the protocol per se, and requiring users to accept terms & conditions falls into that.

[harindra-a]

hi folks, lets push this for post-October discussion. I think there are some interesting directions we can take this, so let's hold discussion for when we have a bit more time. Maybe we nominate a subgroup to investigate it post-October.

I annotated/labeled this issue/thread to "After-1.0.0" to focus efforts for Basel, hope that's OK with everyone.