Re: prov-dm - when are constructs too domain specific?

On Wed, Dec 7, 2011 at 10:25, Paul Groth <p.t.groth@vu.nl> wrote:
> Personally, I'm in favor of being more liberal here in terms of including
> constructs. Primarily because our purpose is interchange and having some
> what can be considered domain specific constructs will greatly help in
> facilitating provenance interchange. This is especially the case for common
> cases.

I agree that we should provide some general, yet domain-specific
constructs, as they would encourage provenance exchange that is more
valuable and specific than just "something used something else and
made something new".

However I don't think these should be influencing the "core" model or
required for someone to say they are "PROV enabled".

Also I believe such domain-specific constructs should be informed by
actual needs from those domains, and not just made up on the fly,
which is the feeling I get from some of the current "Common relations"
constructs like wasSummaryOf. (What about wasIllustrationIn?
discussed? disagreedWith?)


So while I'm OK with having a semi-general relation like
"wasRevisionOf" - these should be kept separate in some kind of
"publication"-centric extension, as it would probably not be useful
for instance to describe biological processes or where my coffee beans
came from.

The more domain-specific constraints we add, the more likely is we get
them wrong, in particular if we are not domain experts.

For instance, I work with scientific workflows, and could help with
making an extension for provenance of workflows, but I would need help
from many other workflow experts as well to be able to form something
that is generally useful amongst most workflow systems, but such a
task could then easily become overwhelming and worthy its own
committees.


(I think it should be a sign of success for PROV if we see such
committees and approaches starting up!)

-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Wednesday, 14 December 2011 15:51:11 UTC