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

Late response - catching up on emails...

I agree with you that the key criteria for domain specific structures should be 
based on interchange/interoperability.

Where I would maybe differ is that to have constructs that are too specific may 
impair interoperability as much as not having sufficiently specific constructs, 
by virtue of (a) being harder to understand, and (b) potentially over-specifying 
a particular case hence reducing scope of applicability.

As a rule of thumb, I would suggest that specific concepts that are common 
across most anticipated domains of use (e.g. people, organizations, software) 
are probably appropriate to include, but others (e.g. biological agents were 
mentioned previously) are not.  The framework should make it easy for 
applications to specialize concepts without masking any information that would 
be recognizable using common constructs.  (What constitutes "easy" here is a 
matter for debate - e.g. subclassing and assumption of associated inference 
capabilities is such a debatable point.)

#g
--

On 07/12/2011 10:25, Paul Groth wrote:
> Hi Satya, All:
>
> I noticed that many of the issues Satya raised (see below) talked about terms
> being domain specific. For example, collections and the typing of agent.
>
> I think we as a group need to figure out where we stand on constructs that can
> be considered domain specific. I would like to just get your general thoughts on
> this as I think getting a broad agreement on where we roughly draw the line on
> too much domain specificity will help us resolve these issues.
>
> 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.
>
> Anyway, I'm interested to hear your thoughts.
>
> Thanks,
> Paul
>
>
>
> Issues to do with Domain Specificity
> PROV-ISSUE-185
> PROV-ISSUE-188
> PROV-ISSUE-192
> PROV-ISSUE-193
> PROV-ISSUE-194
> PROV-ISSUE-198
>

Received on Tuesday, 3 January 2012 14:32:24 UTC