Minimal and Maximal Sets for Privacy and Ethics

[sgoggins]

Working with @moduloone and @katieshilton on this part of the OCDX. Correspondence and document attached.

Hi all,

I've attached a document that I hope can serve as a starting point for the max-set for the privacyEthics() portion of the manifest.

Essentially, I'd like us to consider including two additional fields (highlighted in yellow in the document):

oversightProvenance(): A field that can contain IRB approval numbers. (Should be used in conjunction with the oversight() field).
tosCompliance(): Which includes three sub-fields, complianceAssertion(), tosVersionInformation(), and tosArchive(). The idea behind this is to create a way for a researcher to indicate that, yes their collection was compliant at the time of data collection (or in a rare case, that no it was not, but we collected it anyways), provide info on what version of a TOS the data was collected under, and include a pointer to an archived copy of the TOS if available.

Cardinality info should be in the attachment.

Finally, while I think this a good start point for the max set, I'm hoping that we may have the oppurtunity to actually talk to some of the early OCDX manifest users (or manifest creators) in order to better understand whether or not these privacy and ethics fields are meeting their needs so we can revise as appropriate.

Thoughts?

• Nick
  OCDX maxset.docx

[AniKarenina]

The only thing I can think that might need to be checked on this is
whether it’s adequately broadly stated/defined to accommodate non-US
oversight models. I suspect so, but worth verifying if it hasn’t been
already.

tosArchive() seems like a highly rarified detail for anyone to be
recording proactively, so the odds anyone can answer it may be
extremely low. And with this kind of thing, the more you ask for, the
less you get.

One of my concerns is that asking for things that people didn’t know
to record and/or can’t reconstruct could frustrate/discourage
participation. Instead of skipping an item or using “no assertion”
they may decide not to do any of it at all, and making items optional
doesn’t necessarily solve that problem.

Anyway, just $0.02 based on years of hearing people say that asking
for too much is counterproductive when it comes to voluntary
contributions of data and metadata!

On August 9, 2016 at 11:52:26 PM, Sean P. Goggins
([email protected]) wrote:

Working with @moduloone and @katieshilton on this part of the OCDX. Correspondence
and document attached.

Hi all,

I've attached a document that I hope can serve as a starting point for the max-set for the
privacyEthics() portion of the manifest.

Essentially, I'd like us to consider including two additional fields (highlighted
in yellow in the document):

oversightProvenance(): A field that can contain IRB approval numbers. (Should be used
in conjunction with the oversight() field).
tosCompliance(): Which includes three sub-fields, complianceAssertion(), tosVersionInformation(),
and tosArchive(). The idea behind this is to create a way for a researcher to indicate
that, yes their collection was compliant at the time of data collection (or in a rare case,
that no it was not, but we collected it anyways), provide info on what version of a TOS the
data was collected under, and include a pointer to an archived copy of the TOS if available.

Cardinality info should be in the attachment.

Finally, while I think this a good start point for the max set, I'm hoping that we may have
the oppurtunity to actually talk to some of the early OCDX manifest users (or manifest
creators) in order to better understand whether or not these privacy and ethics fields
are meeting their needs so we can revise as appropriate.

Thoughts?

• Nick
  OCDX maxset.docx

---

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#26

[moduloone]

Hi Ani,

I think you raise some really good points. I think it's reasonable to drop tosArchive() particularly if you are concerned about frustrating participation, which I obviously do not want. I do think that it's still worth keeping in tosVersionInformation() so there is a way to provide the option to create a trail that basically says, "Yes, this was ok to pull/scrape at the time of collection because we used these rules."

The reason I think this is useful is because of the problems that have cropped up in the wake of a number of Twitter's TOS revisionings where datasets collected under one set of rules at time of collection are no longer seen as compliant.

Edit: And I'm looking into the non-US question.

[AniKarenina]

Generally agree on tosVersionInformation() aside from the part where
there’s no standard for “versioning” TOS (that I’ve seen, but I may
have missed it) and even if there were, not everyone would use it, so
we need good examples to keep it from getting confusing. I would have
no idea how to answer that question myself other than
TOS-as-of-date-says-its-OK.

On August 11, 2016 at 4:13:43 PM, Nicholas P ([email protected]) wrote:

Hi Ani,

I think you raise some really good points. I think it's reasonable to drop tosArchive()
particularly if you are concerned about frustrating participation, which I obviously
do not want. I do think that it's still worth keeping in tosVersionInformation() so there
is a way to provide the option to create a trail that basically says, "Yes, this was ok to
pull/scrape at the time of collection because we used these rules."

The reason I think this is useful is because of the problems that have cropped up in the
wake of a number of Twitter's TOS revisionings where datasets collected under one set
of rules at time of collection are no longer seen as compliant.

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#26 (comment)