Re: PROV-ISSUE-89 (what-entity-attributes): How do we find the attributes of an entity? [Formal Model]

On 16/09/2011 23:50, Satya Sahoo wrote:
> Hi Luc,
> My responses are interleaved.
>
> > So here they are:
> >entity(e1,[ company: "Toyota", model: "Corolla", identification="1a"])
> >entity(e2,[ company: "Toyota", model: "Corolla", identification="1a", 
> owner="tom"])
> >entity(e3,[ company: "Toyota", model: "Corolla", identification="1a", 
> owner="luc"])
>
> ok.
>
> >wasDerivedFrom(e3,e2)  (since e3 was bought by luc from tom)
>
> This is also ok - this is what I meant in my previous mail (e1 and e2 
> can exist, but it should be explicit that e2 is e1 with additional 
> "necessary" attributes.)
>
> > But how does it work in an open world context, when there may be 
> other assertions in your triple store, e.g. e1 hasColor blue. But the 
> color property is >not one of the attributes  used in any of e1, e2, e3.
>
> We make additional assertions that e1 hasColor blue etc. - I am not 
> sure I understand the problem in adding these new assertions to 
> existing assertions (the ability to add the new assertions is the 
> "open world assumption").

I must admit, I am also not clear on why we need to separate the two 
kinds of properties/attributes, I mean characterizing and not 
characterizing. The conceptual model does not make this distinction, and 
if we are to implement it correctly in the formal model, IMO we need to 
first discuss it and clarify it at the level of the conceptual model 
first. Specifically, "What is does it mean that given attribute that is 
associated to an Entity is not a characterizing attribute?"

Khalid
>
> Going back to your original mail:
> >The conceptual model defines an entity in terms of an identifier and a 
> list of attribute-value pairs. It is indeed crucial for the asserter 
> to identify the >attributes that have been frozen in a given 
> entity.Currently, the ontology does not seem to identify these attributes.
>
> If you define an ontology class called "Toyota Corolla Car" and 
> define a set of "necessary" restrictions using attribute-value pairs 
> then all entities that are asserted to be instances of this class must 
> have those attribute-value pairs asserted for them. For example, for 
> entity e1 to be instance of the "Toyota Corolla Car" class:
> 1. It needs to be a car (maybe inherited from the parent class "Car") 
> - with a set of defined attributes like hasPart wheels, steering 
> mechanism etc.
> 2. It needs to have an attribute called hasManufacturer and the value 
> of this attribute has to be "Toyota"
> 3. It needs to have an attribute called hasModelType and the value of 
> this attribute has to be "Corolla"
>
> These "necessary" attributes have to be defined apriori by the 
> ontology developer to create a specific class and this is not related 
> to "open world assumption". If color is defined to be a "necessary" 
> attribute then the asserter has to define the attribute for the entity 
> instance and assign a value else it cannot be an instance of a "Toyota 
> Corolla Car" (maybe "Blue Toyota Corolla Car" is more appropriate 
> class for that restriction).
>
> > To say that these attributes could be found by looking at all the 
> properties for this entity does not work with an open world assumption.
> As above - the "necessary" attributes are not made optional by the 
> open world assumption.
>
> On a separate note (not related to open world assumption), we can have 
> a set of "necessary and sufficient" conditions for a class that allows 
> any entity instance to be "automatically" (by a reasoner) inferred to 
> be a member of a specific ontology class (also referred to as 
> "defined" class).
>
> Thanks.
>
> Best,
> Satya
>
> On Thu, Sep 8, 2011 at 12:31 PM, Luc Moreau <L.Moreau@ecs.soton.ac.uk 
> <mailto:L.Moreau@ecs.soton.ac.uk>> wrote:
>
>     Hi Satya,
>
>
>     On 09/08/2011 05:16 PM, Satya Sahoo wrote:
>>     Hi Luc,
>>     My responses are interleaved:
>>
>>     > "instance" indeed e.g.:  entity(e0, [ type: "File", location:
>>     "/shared/crime.txt", creator: "Alice" ])
>>     ok
>>
>>     > Using the Provenance Abstract Syntax Notation, I could assert
>>     two entities (instances)
>>     > entity(e1,[ company: "Toyota", model: "Corolla"])
>>     > entity(e2,[ company: "Toyota", model: "Corolla", owner="tom"])
>>     The entity we are referring to is an instance of "Toyota Corolla
>>     car" and its identifying attribute is "1a", which distinguishes
>>     this instance from other instances of "Toyota Corolla car". As
>>     described in my earlier mail, we first need to decide what are
>>     the "necessary" attributes of an instance and depending on that
>>     we can enumerate them for uniquely "identifying" that entity.
>>
>>     So,
>>     entity(e1,[ company: "Toyota", model: "Corolla"]) should include
>>     attribute "vehicle identification number" with value "1a".
>>
>>     entity(e2,[ company: "Toyota", model: "Corolla", owner="tom"]) is
>>     the same entity as e1, but with an additional (non-essential?)
>>     atribute of ownership.
>>
>>     e1 and e2 can exist, but it should be explicit that e2 is e1 with
>>     additional "necessary" attributes.
>
>     Yes, sorry, I should have made the id explicit. So here they are:
>
>     entity(e1,[ company: "Toyota", model: "Corolla", identification="1a"])
>
>     entity(e2,[ company: "Toyota", model: "Corolla",
>     identification="1a", owner="tom"])
>
>     entity(e3,[ company: "Toyota", model: "Corolla",
>     identification="1a", owner="luc"])
>
>     In paticular, we may want to write
>
>     wasComplementOf(e2,e1)
>     wasComplementOf(e3,e1)
>
>     and also that
>
>     wasDerivedFrom(e3,e2)  (since e3 was bought by luc from tom)
>
>>
>>
>>     > How do I know the attributes of each entity: company/model for
>>     e1 and company/model/owner for e2?
>>     I am not sure I completely understand the query - but we would
>>     follow the attributes/property links associated with both e1 and
>>     e2 to retrieve the appropriate values.
>>
>
>     But how does it work in an open world context, when there may be
>     other assertions in your triple
>     store, e.g. e1 hasColor blue.
>
>     But the color property is not one of the attributes  used in any
>     of e1, e2, e3.
>
>     Luc
>
>
>>     Thanks.
>>
>>     Best,
>>     Satya
>>
>>     On Thu, Sep 8, 2011 at 10:30 AM, Luc Moreau
>>     <L.Moreau@ecs.soton.ac.uk <mailto:L.Moreau@ecs.soton.ac.uk>> wrote:
>>
>>         Hi Satya,
>>
>>         Responses interleaved
>>
>>
>>         On 09/06/2011 06:26 PM, Satya Sahoo wrote:
>>>         Hi Luc,
>>>         To clarify a few points:
>>>         1. In case of the provenance ontology (formal model), there
>>>         are two types of information resources (entities) - a class
>>>         of entities (TBox or part of ontology schema) and individual
>>>         entities (ABox or instances of an entity class).
>>>
>>>         2. There are two types of attributes - (a) attributes
>>>         necessary for an information resource to have to be member
>>>         of a class of entities (intensional definition), and (b) set
>>>         of attributes associated with a class of entities, but they
>>>         are not necessary for an information resource to be member
>>>         of a class of entities
>>>
>>>         Given the above points,
>>>         > The conceptual model defines an entity in terms of an
>>>         identifier and a list of attribute-value pairs.
>>>         Does this identify an "instance" entity or "class" entity?
>>>
>>
>>         "instance" indeed
>>
>>         e.g.:  entity(e0, [ type: "File", location:
>>         "/shared/crime.txt", creator: "Alice" ])
>>
>>
>>
>>>         >  It is indeed crucial for the asserter to identify the
>>>         attributes that have been frozen in a given entity.
>>>         Seems to refer to "instance" entity - for those attributes
>>>         that form part of the intensional definition of the "class"
>>>         entity.
>>>         For example, a Toyota Corolla Car with vehicle
>>>         identification number "1a" will have "frozen" values of
>>>         "toyota" and "corolla" for attributes "manufacturing
>>>         company" and "car model name". But, it can have "variable"
>>>         values of "ann" or "tom" for attribute "current owner".
>>>
>>         Using the Provenance Abstract Syntax Notation, I could assert
>>         two entities (instances)
>>
>>         entity(e1,[ company: "Toyota", model: "Corolla"])
>>
>>         entity(e2,[ company: "Toyota", model: "Corolla", owner="tom"])
>>
>>
>>         How do I know the attributes of each entity: company/model for e1
>>         and company/model/owner for e2?
>>
>>         Cheers,
>>         Luc
>>
>>
>>
>>>         With the above description and examples, can you please
>>>         clarify your point again?
>>>
>>>         Thanks.
>>>
>>>         Best,
>>>         Satya
>>>
>>>         On Fri, Sep 2, 2011 at 4:52 AM, Provenance Working Group
>>>         Issue Tracker <sysbot+tracker@w3.org
>>>         <mailto:sysbot%2Btracker@w3.org>> wrote:
>>>
>>>
>>>             PROV-ISSUE-89 (what-entity-attributes): How do we find
>>>             the attributes of an entity? [Formal Model]
>>>
>>>             http://www.w3.org/2011/prov/track/issues/89
>>>
>>>             Raised by: Luc Moreau
>>>             On product: Formal Model
>>>
>>>             The conceptual model defines an entity in terms of an
>>>             identifier and a list of attribute-value pairs. It is
>>>             indeed crucial for the asserter to identify the
>>>             attributes that have been frozen in a given entity.
>>>
>>>             Currently, the ontology does not seem to identify these
>>>             attributes.
>>>
>>>             To say that these attributes could be found by looking
>>>             at all the properties for this entity does not work with
>>>             an open world assumption.
>>>
>>>             What mechanism do we have to identify these attributes?
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>         -- 
>>         Professor Luc Moreau
>>         Electronics and Computer Science   tel:+44 23 8059 4487  <tel:%2B44%2023%208059%204487>
>>         University of Southampton          fax:+44 23 8059 2865  <tel:%2B44%2023%208059%202865>
>>         Southampton SO17 1BJ               email:l.moreau@ecs.soton.ac.uk  <mailto:l.moreau@ecs.soton.ac.uk>
>>         United Kingdomhttp://www.ecs.soton.ac.uk/~lavm  <http://www.ecs.soton.ac.uk/%7Elavm>
>>              
>>
>>
>
>     -- 
>     Professor Luc Moreau
>     Electronics and Computer Science   tel:+44 23 8059 4487  <tel:%2B44%2023%208059%204487>
>     University of Southampton          fax:+44 23 8059 2865  <tel:%2B44%2023%208059%202865>
>     Southampton SO17 1BJ               email:l.moreau@ecs.soton.ac.uk  <mailto:l.moreau@ecs.soton.ac.uk>
>     United Kingdomhttp://www.ecs.soton.ac.uk/~lavm  <http://www.ecs.soton.ac.uk/%7Elavm>
>
>

Received on Saturday, 17 September 2011 10:51:35 UTC