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

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<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
>>
>>
>>
>>
>>
>
>