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

On Sep 16, 2011, at 6:50 PM, 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"]) 

:e_1
	a prov:Entity;
	dcterms:identifier "1a";
	vehicle:make <http://dbpedia.org/resource/Toyota>;
	vehicle:model <http://dbpedia.org/resource/Toyota_Corolla>;
	vehicle:vin "XYZ123";
	prov:wasComplementOf <http://www.nhtsa.gov/id/vin/XYZ123>;
.
:e_2
	a prov:Entity;
	dcterms:identifier "1a";
	vehicle:make <http://dbpedia.org/resource/Toyota>;
	vehicle:model <http://dbpedia.org/resource/Toyota_Corolla>;
	<http://purl.org/vocab/frbr/core#owner> <http://data.semanticweb.org/person/tom-heath>;
	vehicle:vin "XYZ123";
	prov:wasComplementOf <http://www.nhtsa.gov/id/vin/XYZ123>;
.
:e_3
	a prov:Entity;
	dcterms:identifier "1a";
	vehicle:make <http://dbpedia.org/resource/Toyota>;
	vehicle:model <http://dbpedia.org/resource/Toyota_Corolla>;
	<http://purl.org/vocab/frbr/core#owner> <http://data.semanticweb.org/person/luc-moreau>;
	vehicle:vin "XYZ123";
	prov:wasComplementOf <http://www.nhtsa.gov/id/vin/XYZ123>;
.


> 
> ok.
> 
> >wasDerivedFrom(e3,e2)  (since e3 was bought by luc from tom)


:e_3 prov:wasDerivedFrom :e_2 .

:pe_4
	a prov:ProcessExecution, prov:Entity, commerce:Purchase;
	dcterms:date "2011-09-20";
	prov:used [
		a commerce:Seller, prov:Role, prov:Entity;
		prov:wasComplementOf <http://data.semanticweb.org/person/tom-heath>;
	];
	prov:used [
		a commerce:Buyer, prov:Role, prov:Entity;
		prov:wasComplementOf <http://data.semanticweb.org/person/luc-moreau>;
	];
	prov:used :e2; # The car as owned by Tom, described above and below.
	prov:used [
		a commerce:Payment, prov:Role, prov:Entity;
		rdf:value 25000;
		muo:measuredIn <http://dbpedia.org/resource/Pound_sterling>;
	];
	prov:generated :e_3; # The car as owned by Luc, described above and below.
.

:e_2 a commerce:GivenGoods, prov:Role, prov:Entity .
:e_3 a commerce:ReceivedGoods, prov:Role, prov:Entity .



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


Since the assertions are added to the Entity and not the invariant car itself (<http://www.nhtsa.gov/id/vin/XYZ123>), the triples never overlap and you do not have any contradictions. Further, triples directly describing the invariant <http://www.nhtsa.gov/id/vin/XYZ123> do not overlap with the triples asserted on the Entities that contextualize the car's use (or observation).


> 
> 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").


Is that quite right?
From my understanding,
OWA says you can't prove something false just because it isn't asserted to be true, which is slightly different than "people can add new assertions").


> 
> Going back to your original mail:
> 
> 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

The asserter does _not_ need to define the attribute. _This_ is where the open world comes in. If the asserter fails to define the :colour, and we accept the view of the ontology that has the three axioms above, THEN we "know" that the

 :e_1 a :ToyotaCarollaCar .

that the asserter DID assert does indeed have a :colour, whether or not we see the :colour triple sitting around.
We know this because the ontology tells us that it has one, even though we don't know what the value is yet. (and it might never be asserted, but we know it still exists).



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


True, you might not see all of them, but you'll find the ones you have. If you want to "know" it has more without actually seeing them asserted somewhere, then you'll need the minCardinality 1 OWL axiom.


> As above - the "necessary" attributes are not made optional by the open world assumption.


[snip]

> 
> Best,
> Satya
> 
> On Thu, Sep 8, 2011 at 12:31 PM, Luc Moreau <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.



Option 3 (beyond SPARQL'ing what you have and knowing minCardinality 1s)

owl:key gives you this; it is in OWL 2 .





>> 
>> 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. You need owl:key


vehicle:Car
    a owl:Class ;
    owl:hasKey ( vehicle:make vehicle:model vehicle:owner vehicle:vin ) . # Though, I'd just use owner and vin since make and model follow from vin.




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


Whoa. Entities up the complement chain? (i.e., prov:wasComplementOf rdfs:range prov:Entity )
I thought we got to ground out to "regular resources", e.g. <http://data.semanticweb.org/person/luc-moreau>, the foaf:Person .
I might be able to get used to it, but it'd be a whole new semantic web :-/




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



Would you accept the rephrasing, "How do I know which attributes to use, such that when their values match the values of asserted for another Entity, I can infer that the two Entities are in fact the same?"
If so, then owl:key give you want you need.
SPARQL wouldn't, and neither would minCardinality 1.




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


They just are not part of the owl:key defined for the class.
It could still be part of a minCardinality 1 on the same class and not affect the owl:key .



> 
> But the color property is not one of the attributes  used in any of e1, e2, e3.



vehicle:Car
	a owl:Class;
	rdfs:subClassOf prov:Entity;
	rdfs:subClassOf [
		a owl:Restriction;
		owl:onProperty vehicle:make;
		owl:minCardinality 1;
	];
	rdfs:subClassOf [
		a owl:Restriction;
		owl:onProperty vehicle:model;
		owl:minCardinality 1;
	];
	rdfs:subClassOf [
		a owl:Restriction;
		owl:onProperty vehicle:owner;
		owl:minCardinality 1;
	];
.

vehicle:color rdfs:domain owl:Thing .

>> 
>>> >  It is indeed crucial for the asserter to identify the attributes that have been frozen in a given entity.



Aren't _ALL_ attributes on an entity "frozen" within the context* that is being described?

* I had severe issues with "frozenness" at the F2F until I learned that the context can have durations >0 time units - i.e., a proper interval.


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



vehicle:current_owner of "ann" and "tom" would __not__ appear on the same Entity, they would appear on separate Entities sharing a common prov:wasComplementOf <http://www.nhtsa.gov/id/vin/XYZ123>  and vehicle:vin "XYZ123" and dcterms:identifier "1a" and :identifier "1a" .




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


Why does this not work? (nope, it's owl:key)

SELECT ?attribute ?value
WHERE {
	:car ?attribute ?value .
}


>>> 
>>> 
>>> On Fri, Sep 2, 2011 at 4:52 AM, Provenance Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:
>>> 
>>> PROV-ISSUE-89 (what-entity-attributes): How do we find the attributes of an entity? [Formal Model]


Why does this not work? (nope, it's owl:key)

SELECT ?attribute ?value
WHERE {
	:car ?attribute ?value .
}



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


Do SPARQL and/or owl:minCardinality 1 work? (nope; it's owl:key)



SELECT ?attribute ?value
WHERE {
	:car ?attribute ?value .
}




vehicle:Car
	a owl:Class;
	rdfs:subClassOf prov:Entity;
	rdfs:subClassOf [
		a owl:Restriction;
		owl:onProperty vehicle:make;
		owl:minCardinality 1;
	];
	rdfs:subClassOf [
		a owl:Restriction;
		owl:onProperty vehicle:model;
		owl:minCardinality 1;
	];
	rdfs:subClassOf [
		a owl:Restriction;
		owl:onProperty vehicle:owner;
		owl:minCardinality 1;
	];
.


-Tim