- From: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Date: Mon, 09 May 2016 21:16:21 +0100
- To: W3C Prov <public-prov-comments@w3.org>
- CC: Reed Gelzer <rgelzer@provider-resources.com>
- Message-ID: <5730F015.9060407@ecs.soton.ac.uk>
Hi all,
I am forwarding this message to the mailing list. If you want
to respond, please copy the author in your response.
Regards,
Luc
-------- Original Message --------
Subject: RE: Call for position statements "PROV: Three Years Later"
Date: Wed, 4 May 2016 19:06:09 +0000
From: Reed Gelzer <rgelzer@provider-resources.com>
To: Luc Moreau <l.moreau@ecs.soton.ac.uk>,
"provenance-challenge@ipaw.info" <provenance-challenge@ipaw.info>, W3C
Prov <public-prov-comments@w3.org>
Thank you for this call for input.
I am, as will soon be evident, a non-expert user of the PROV work.
One of our HL7 workgroups has found the W3C Provenance work
extraordinarily helpful in modeling Provenance in Electronic Health
Records Systems.
>From that experience, copying elements from your list below, here are
some ideas/ possible position statement topics. If any of these find
resonance in your community, I'd welcome (request) help in translating
them into acceptable format for your upcoming event.
In sum, they all involve the boundary (or boundaries) between what I'll
try to describe as source reliability attributes vs. provenance
attributes. To grossly over-simplify, it has seemed to me that W3C
Provenance is about the history of a data object and its relationships
with other data objects. It is NOT about the circumstances of at least
one type of data object's first creation. That one type of data object
where it is intended to represent an act or event that is occurring or
has occurred in the real world, such as a data object representing the
first capture of a patient care act or event.
My limited understanding of PROV is that it was built for the world wide
web and in that context Provenance is agnostic about whether or not the
object meets a given end-use or end-users requirements for accuracy, for
example. Provenance is only about assurance that this particular object
can be traced back to its first instantiation as a data object
somewhere. Whether or not the "source" is or was ever sufficiently
accurate is out of scope for Provenance. Thus attributes or
qualifications for various end-use requirements for "source accuracy"
belong to a different domain than PROV.
If this is indeed a proper understanding, then the rest may be useful.
If not a proper understanding then I'm looking forward to correction.
If a proper understanding then it may be useful to hear more about our
"experiment" with regard to source reliability attributes (we are using
the term Origination) as intended to be about the conditions for the
creation of data objects constrained (for our purposes at HL7's EHR
Workgroup) to only where those objects are intended to represent the
first capture into a system (any system) acts or events in "the real world".
For a relatively trivial example, if a reported patient blood pressure
is from a U.S. FDA regulated device, then provenance will suffice
because there is a referenceable resource that can be identified as the
source and, given the already met parameters of FDA regulation
requirements, knowing its source also offers evidence that the source
has accuracy parameters XYZ that can be adjudicated as sufficient or
insufficient for the end use purpose.
On the other hand if the blood pressure was measured by a human
operator, it may be of interest to know additional information about its
origination, other than "not by an FDA regulated automated device", such
as whether that measurement was made by an individual with ABC
credentials. A representative end use seeking such information could
be, for example, to support data quality variance studies by performing
comparisons between machine-measured vs. human measured vs. measured by
humans of different credentials.
Less trivial examples exist in, for example, requiring "levels of
assurance" for key data determinants for inclusion or exclusion from use
by clinical decision support systems.
I understand that this clumsy attempt at description will itself call
forth many critical assessments. Hopefully somewhere in the miasma the
intended kernel is apparent to some.
If any or some of this seems pertinent, then perhaps one or more of
these below would be of use (using some of this Call's elements)
* Impact of provenance-What are the boundaries of Provenance? What
does it represent? What does it NOT represent?
* Presentation and explanation of provenance to users-Similarly, for
explaining to others, what are the boundaries of Provenance? What
are the questions users ask, what are the "trust attributes" of
interest to users that sufficiently describe data quality factors
for a given data object in order to support end-user determination
of suitable "level of assurance" for their particular need
* Multi-level provenance (provenance of provenance)-What are the
boundaries of Provenance?
Perhaps some of the above will suggest utility for one or more of these
from the Call
* Interoperability issues across serializations or within serializations-
* Missing features, expressivity shortcomings
* Adoption hurdles
* Security and provenance, provenance and signatures (This latter,
"signatures", is of high interest in healthcare now. Digital
signatures, binding each service provider's ID to the data
representing the work each did, is being contemplated and modeled in
the healthcare sector as the best, and possibly only practical way
to indelibly bind each author of a multi-author object to each's
contribution to that object. This need is created by the fact that
EHRs are not currently designed to accurately capture work
attribution. This is of special interest for healthcare where
there are various common practices for having clinical services
provided by individual A, but the record of that service is
"authored" or attributed to individual B. Among other problems,
this means it is difficult to impossible to evaluate the resource
costs of patient care since the attributed resource may not have
actually done the work.)
* Embedding provenance in various types of documents
* Graphical representation of provenance
* Inter-operability across standards
* Extensions of PROV for additional requirements in different domains
and applications
* Abstraction of PROV records
In sum, this question:
For at least one type of data object, those intended to represent the
first capture of an act or event in "the real world" into a digital info
system, are the system attributes or conditions of "capture" outside the
scope of PROV?
In our recent HL7 discussions, the PROV work has been very helpful.
Within those discussions some advocate for a position that PROV is of
supreme importance for defining representations of the history of
objects and derivations of successive objects but that PROV is agnostic
about system activities and associated characteristics of the "first
creation" which could be the domain of "To Originate".
If that makes sense, does the concept of "Originate" or "Origination"
have utility for describing a domain outside of ("upstream" of) PROV?
Draft definition "To Originate (v): To initiate entry of data objects
as potential content for an EHR record." (This permits the option of
treating that object as ephemera, until it is also Retained)
I apologize if none of the above has sense or otherwise is of no use to
the W3C community and look forward to further education from your
informed community either way.
Regards,
RDGelzer
*Reed D. Gelzer*
*Reed D. Gelzer, MD, MPH*
*HIT Policy and EHR Specialist*
*Co-Chair, HL7 EHR Systems Workgroup*
*Co-Facilitator, HL7 EHR Records Management and Evidentiary Support
Workgroup*
*Provider Resources, Inc.***
2005 West 8th Street, Suite 208
Erie, PA 16505
203-506-5361 Direct
www.Provider-Resources.com <http://www.Provider-Resources.com>
*P***/Please consider the environment before printing this e-mail./**
*From:*Luc Moreau [mailto:l.moreau@ecs.soton.ac.uk]
*Sent:* Thursday, April 28, 2016 7:27 AM
*To:* provenance-challenge@ipaw.info; W3C Prov
*Subject:* Re: Call for position statements "PROV: Three Years Later"
Dear all,
Second and final call for position statements for "PROV: Three Years Later".
Regards,
Luc
On 17/03/2016 19:26, Luc Moreau wrote:
A workshop endorsed byW3C <https://www.w3.org/>atProvenance Week
<http://www2.mitre.org/public/provenance2016/>, June 6, 2016,
Washington DC.
http://provenanceweek.org/2016/p3yl/
Organizing Committee
Luc Moreau (chair)
University of Southampton
Phil Archer
W3C
Reza B'Far
Oracle
Yolanda Gil
Information Science Institute
Paul Groth
Elsevier Labs
Timothy Lebo
Rensselaer Polytechnic Institute
Deborah Nichols
The MITRE Corporation
Curt Tilmes
National Aeronautics and Space Administration
Abstract
Provenance Week 2016 will take place three years after the
publication of the PROV recommendations and notes. The purpose
of this workshop is twofold: 1) to collect practical experiences
with using PROV in real-world applications so that we can take
stock of its impact, and 2) to identify interoperability
challenges with the current PROV specifications. The aim is to
develop a community consensus around the priorities for PROV.
Background
Provenance, defined as a record that describes the people,
institutions, entities, and activities involved in producing,
influencing, or delivering a piece of data or a thing, is
crucial in deciding whether information is to be trusted, how it
should be integrated with other diverse information sources, and
how to give credit to its originators when reusing it. In many
environments, such as the Web or the medical context where users
find information that is uncertain or questionable, provenance
can help those users to make trust judgements.
In 2013, the World Wide Web Consortium published PROV, a
standard for expressing, sharing, and discovering provenance on
the Web.. It consists of a conceptual data model (PROV-DM
<https://www.w3.org/TR/prov-dm/>), an OWL2 ontology (PROV-O
<https://www.w3.org/TR/prov-o/>), a textual notation (PROV-N
<https://www.w3.org/TR/prov-n/>), a set of constraints to check
the consistency of provenance (PROV-CONSTRAINTS
<https://www.w3.org/TR/prov-constraints/>), an XML schema
(PROV-XML <https://www.w3.org/TR/prov-xml/>), conventions for
sharing and discovering provenance (PROV-AQ
<https://www..w3.org/TR/prov-aq/>), and various other more
focused specifications. Since then, PROV has seen adoption in
some flagship applications, continued strong interest by the
academic community, and promising tentative take-up in other
standardization organizations, such asHL7
<https://www.hl7.org/fhir/provenance.html>andOGC
<http://www.opengeospatial.org/projects/initiatives/ows-10>.
Three years later, it is time for provenance practitioners to
take stock, reflect on their practical experiences with using
PROV in their applications, understand the impact of PROV, and
identify interoperability challenges and shortcomings with the
current specifications. We invite the community to submit short
position statements, which will be presented in "lightning
talks" at a workshop on June 6, during Provenance Week. Talks
will be grouped by topics of interest. The workshop organisers
will act as facilitators, with the aim to develop a community
consensus around the priorities for PROV. Position statements
will be published online as a record of the workshop.
Topics of Interest
The following is a non-exhaustive list of topics for position
statements reporting on*experiences*and*impact*:
* API and software that use PROV
* Datasets and resources that use PROV
* Impact of provenance
* Scalability
* Presentation and explanation of provenance to users
* Multi-level provenance (provenance of provenance)
* Tradeoff and choices of different serializations
The following is a non-exhaustive list of topics for position
statements reporting on*interoperability*and*requirements*:
* Interoperability issues across serializations or within
serializations
* Missing features, expressivity shortcomings
* Adoption hurdles
* Security and provenance, provenance and signatures
* Embedding provenance in various types of documents
* Graphical representation of provenance
* Inter-operability across standards
* Extensions of PROV for additional requirements in different
domains and applications
* Abstraction of PROV records
Authors are strongly encouraged, where appropriate, to make an
explicit link between requirements and application needs.
Workshop Format
Following this call for position statements, the workshop will
be structured as follows.
* "Lightning talks" grouped by themes
* Open discussion about experiences and priorities
* Next steps.
Timetable
* March 18, 2016: Call published
* May 11, 2016: Deadline for submission
* May 15, 2016: Workshop programme published
* May 20, 2016:Registration closes
<http://www2.mitre.org/public/provenance2016/contact.html>
* June 6, 2016: Workshop
Submission Procedure
Submit short position statements (ideally less than a page)
throughhttps://easychair.org/conferences/?conf=pw2016(please
select the track "PROV: Three Years Later").
To facilitate publication on the Web, authors are encouraged to
submit documents in HTML, using theRASH framework
<https://github.com/essepuntato/rash>(Research Articles in
Simplified HTML). Mutliple submissions for different experiences
and/or requirements are welcome. As we are keen to gather as
many experiences and requirements as possible, it is acceptable
for authors to submit position statements, even if they cannot
physically attend the workshop, as long as they inform the
organizers..
Venue
ProvenanceWeek 2016
<http://www2.mitre.org/public/provenance2016/index.html>, June
6-9, 2016, is being hosted byThe MITRE Corporation
<http://www2.mitre.org/public/provenance2016/venue.html>in
McLean, Virginia, USA, a short metro ride from Washington D.C.
The workshops IPAW and TAPP will be co-located during the week.
The workshop "PROV: 3 Years Later" will take place on the
afternoon of June 6. Entry to the workshop is free but we need
to know who is coming (note that registrations close on May
20!). All registered attendees will be listed on the workshop
Web site. Registration is through the Provenance
Weekregistration page
<http://www2.mitre.org/public/provenance2016/registration.html>.
Participants are cordially invited to register for subsequent
Provenance Week events.
--
Professor Luc Moreau
Head of the Web and Internet Science Group
Electronics and Computer Science tel: +44 23 8059 4487
University of Southampton twitter: @lucmoreau
Southampton SO17 1BJ, UKhttp://www.ecs.soton.ac.uk/~lavm <http://www.ecs.soton.ac.uk/%7Elavm>
--
Professor Luc Moreau
Head of the Web and Internet Science Group
Electronics and Computer Science tel: +44 23 8059 4487
University of Southampton twitter: @lucmoreau
Southampton SO17 1BJ, UKhttp://www.ecs.soton.ac.uk/~lavm <http://www.ecs.soton.ac.uk/%7Elavm>
This email is confidential and solely intended for the recipient(s)
named above. The information contained in this transmission is
proprietary or privileged and may be subject to protection under the
law, including the Health Insurance Portability and Accountability Act
(HIPAA). If you are not the intended recipient, you are notified that
any use, distribution or copying of the message is strictly prohibited
and may subject you to criminal or civil penalties. If you received this
transmission in error, please contact the sender immediately by replying
to this email and delete the material from any computer.
Received on Monday, 9 May 2016 20:17:14 UTC