Re: PROV-ISSUE-65 (domain-specific-info): How is domain specific data combined with the generic model [Conceptual Model]

Hi Simon,
> I am not clear how rdfs:subClassOf and rdfs:subPropertyOf translate into
inclusion of domain >information in the conceptual model / PIL, and this is
exactly the kind of thing I was pushing to be >clarified.
This is my perspective flowing from my understanding how the conceptual
model and the formal model relate to each other:
rdfs:subClassOf in the conceptual model translates to "specialization." For
example file is a specialization of entity (similarly for
rdfs:subPropertyOf).

In the conceptual model and formal model documents, we should include the
above details, that is the mechanism for extending the provenance model for
domain-specific (under "extensibility" section).

I am not sure if you were suggesting to describe domain-specific details
(royal society etc.) in the conceptual model document (except as part of the
examples)?

Thanks.

Best,
Satya



On Thu, Aug 4, 2011 at 11:16 AM, Simon Miles <simon.miles@kcl.ac.uk> wrote:

> Hi Satya,
>
> I agree that it sounds a sensible approach for the formal model.
>
> The important point is that however we explain how to include
> domain-specific information in the conceptual model should match the
> way we allow it in the formal model.
>
> I am not clear how rdfs:subClassOf and rdfs:subPropertyOf translate
> into inclusion of domain information in the conceptual model / PIL,
> and this is exactly the kind of thing I was pushing to be clarified.
>
> Thanks,
> Simon
>
> On 4 August 2011 16:01, Satya Sahoo <satya.sahoo@case.edu> wrote:
> > Hi,
> > In ontology engineering we have the notions of a "upper-level
> ontology(s)"
> > and "domain-specific ontology(s)". The upper-level ontology - the PIL
> > provenance model in our case, is extended to model domain specific
> details -
> > the royal society details described by Simon, using sub class
> > (rdfs:subClassOf) and sub property links (rdfs:subPropertyOf).
> > This allows different applications to "subscribe" to a common upper-level
> > ontology and add their own domain-specific details as needed without
> > affecting other applications.
> > Thanks.
> > Best,
> > Satya
> > p.s: We did in the context of the Provenir ontology earlier for
> biomedicine
> > and taverna [1] - see Quick Links
> > [1] http://wiki.knoesis.org/index.php/Provenir_Ontology
> >
> >
> >
> >
> > On Thu, Aug 4, 2011 at 3:51 AM, Graham Klyne <GK@ninebynine.org> wrote:
> >>
> >> I'd like to add:
> >>
> >> I think it is important that when domain specific information is added,
> it
> >> appears in such a way that applications that do not understand it can
> safely
> >> ignore it and still be able to use the underlying generic provenance
> >> information.
> >>
> >> This shouldn't be hard to achieve, but I think it's an important
> principle
> >> to underpin extensibility.
> >>
> >> #g
> >> --
> >>
> >> Provenance Working Group Issue Tracker wrote:
> >>>
> >>> PROV-ISSUE-65 (domain-specific-info): How is domain specific data
> >>> combined with the generic model [Conceptual Model]
> >>>
> >>> http://www.w3.org/2011/prov/track/issues/65
> >>>
> >>> Raised by: Simon Miles
> >>> On product: Conceptual Model
> >>>
> >>> Any provenance data will be a mixture of PIL constructs and
> >>> domain-specific information, e.g. file names, the Royal Society's
> >>> membership, the event of the RS's foundation, etc. By domain-specific,
> I
> >>> just mean things not defined in the conceptual model. It is not clear
> in the
> >>> current document where this domain-specific information goes.
> >>>
> >>> There are a couple of hints about where it might go:
> >>>
> >>> 1. In the example, the attribute values appear to be domain-specific,
> >>> e.g. "Alice" is not a generic part of the model. The attribute names
> might
> >>> be domain-specific, as I don't think "type", "location", "creator" or
> >>> "content" are defined in the model, but that might be a mistake in the
> >>> model. Can attribute types be domain-specific?
> >>>
> >>> 2. Section 5.12 says that "there are numerous ways in which location
> can
> >>> be specified", suggesting that it is made a domain-specific issue. I'm
> not
> >>> clear whether the list of examples, "coordinate, address..." are
> examples of
> >>> attribute types or something else. It is said that "Location is an
> OPTIONAL
> >>> characteristics of BOB". I'm not sure if "characteristic" is related to
> >>> "attribute", and if this is implying a generic attribute type called
> >>> "location".
> >>>
> >>> But are there additional ways to include domain-specific information
> >>> other than attribute types and values? It may be trivial to address,
> but
> >>> seems important to make explicit, else it is not clear how to apply the
> >>> language in practice.
> >>>
> >>> Thanks,
> >>> Simon
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> > ______________________________________________________________________
> > This email has been scanned by the MessageLabs Email Security System.
> > For more information please visit http://www.messagelabs.com/email
> > ______________________________________________________________________
> >
>
>
>
> --
> Dr Simon Miles
> Lecturer, Department of Informatics
> Kings College London, WC2R 2LS, UK
> +44 (0)20 7848 1166
>
>