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

Hi Stian,

Some of the current relations were motivated by use on the Web and 
common questions. So here's the provenance of the current common relations:

isRevisionOf - motivated by the Version Control use case. Makes it 
easier to model standard version control and document modification using 
the standard. It was identified in the charter as a construct.

wasAttributedTo - attribution is a core part of what people think of 
when describing provenance as described in the incubator group.

original-source: reflected provenance support within google news

wasQuotationOf: to support mark-up of quotations in web pages (e.g. 
blockquote)

wasSummaryOf: I thought it would be a nice thing to have :-)


So I think wasSummaryOf probably should go. Other people have wondered 
about it as well.

For the others, I think there useful and fairly general. Do you thing 
there are others that would be useful?

Thanks,
Paul



Stian Soiland-Reyes wrote:
> 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!)
>

-- 
Dr. Paul Groth (p.t.groth@vu.nl)
http://www.few.vu.nl/~pgroth
Assistant Professor
Knowledge Representation & Reasoning Group
Artificial Intelligence Section
Department of Computer Science
VU University Amsterdam

Received on Wednesday, 14 December 2011 16:26:17 UTC