W3C home > Mailing lists > Public > public-prov-wg@w3.org > September 2011

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

From: Timothy Lebo <lebot@rpi.edu>
Date: Fri, 16 Sep 2011 18:48:55 -0400
Cc: public-prov-wg@w3.org
Message-Id: <A324A03F-431B-44A6-AF87-0C8922CBE995@rpi.edu>
To: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>

On Sep 16, 2011, at 10:06 AM, Stian Soiland-Reyes wrote:

> On Fri, Sep 16, 2011 at 11:32, Khalid Belhajjame
> <Khalid.Belhajjame@cs.man.ac.uk> wrote:
> 
>>> a) Are characterizing attributes meant to also (implicitly or
>>> explicitly) apply directly to the entity?
>> I think implicitly. Let's say that instead of having a "blank node" that is
>> associated to entity with "characterizedBy", and to which we can associate
>> the chatacterizing properties of the entity, "CharacterizingAttributes"
>> allows having an explicit node, to which we can attach such attributes.
> 
> OK, I get that the characterization resource is not necessarily a
> blank node (and not something we can restrict in OWL anyway).

(blank nodes are rdfs:Resources unnamed by URIs; when you see a bnode, it is "just as good" as a URI according to the semantics.
bnodes only become limiting in practice when they ALWAYS avoid being described AFTER they were originally stated)

> 
> 
> What I meant was that if you have:
> 
> :entity :characterizedBy :entityAttrs
> 
> :entityAttrs dc:creator "Khalid";
>    :colour :blue .


Why are these characterizing entities NOT on the Entity itself? 

Entity is _already_ providing us the indirection that we need to distinguish between EVERYBODY'S description of the car IN ALL ETERNITY and _our_ description as we are observing it for our time period and context.


> 
> would it then also be true that:
> 
> :entity dc:creator "Khalid";
>    :colour :blue .
> ?


^^^ this is what we should be asserting to begin with.
We're missing the prov:wasComplementOf to cite the "invariant" car:

> :entity dc:creator "Khalid";
      prov:wasComplementOf <http://toyota.com/id/vin/484570q48948dhd> .
      vehicle:vin "484570q48948dhd";
      wgs:lat 45;
     wgs:long 100;
>    :colour :blue .
> ?

^^^ when we're saying that colo[u]r of the car is blue, we're only saying it within the context of this Entity.
(I'm ignoring the dc:creator b/c that should probably be asserted using PROV :-)
When I run into an Entity and I see that it is (was) :blue, I ask, "WHAT was :blue?"
The first cut answer is "the thing with vehicle:vin "484570q48948dhd" at <45,100>. (THIS is done by asking for all of :entity's prov:characterizingProperties - or could also be simply done by asking for all RDF properties)

One of the SPECIAL characterizingProperties is prov:wasComplementOf, which is pointing at a URI of the "invariant" car in my driveway.
Digging up the wasComplementOf value answers a second cut answer to "WHAT is blue?"



> 
> 
> That is the semantic I get from reading the model document, but in OWL
> this would be quite tricky to enforce or guide. Someone might easily
> state:
> 
> :entity :colour :red .
> 
> and contradict the :characterizedBy - what is now the colour of the
> :entity? (assuming that :colour is a functional property)
> 
> 
> 
> 
>>> b) Are nested object properties included in the characterisation (like
>>> a filter), or just auxiliary attributes?
>> Any data or object property can be associated with CharacetrizingAttributes.
> 
> Fine. But can the properties of those objects, are they included in
> the characterization attributes, or just happen to be properties of an
> entity that happens to be used in the characterization?
> 
> This is the Luc-in-Southampton-problem:
> 
> :car a prov:Entity ;
>    prov:characterizedBy :carCharacter.
> 
> :carCharacter :owner <http://example.com/luc> ;
>    :colour blue .


^^^ again, too much indirection; we have it already with Entity:
:car a prov:Entity;
   :owner :luc;
   prov:wasComplementOf toyota:vin98549865hddh
.
:owner rdfs:subPropertyOf prov:characterizingProperty . # Though, why can't we just look at ALL RDF properties as characterizing entities?

> 
> <http://example.com/luc> foaf:based_near :Southampton .
> 
> 
> now - if <http://example.com/luc> (who is not declared as an
> prov:Entity here)

:luc a foaf:Person here.

> moves to Oxford, would he then still be the owner of
> the :car by this characterization?

yes or no. nothing has said anything either way. (open world)

> 
> 
> I think it would simplify things if the characterisation properties is
> only one level down.


One level down, or simply directly on the :Entity?
Simply on the prov:Entity allows any level of "down" because it's just domain-specific OWL axioms.

> What about properties implied through class
> membership and inference?
> 
> Say :colour implies the class :Coloured, as a subclass of :Surfaced
> with a requirement of :surface property having owl:someValuesFrom
> :Surface , then :surface would by inferencing also be included in
> :carCharacter. This can of course be powerful way to express complex
> characterisations hierarchies, but I am of the opinion that this
> primarily complicates things.
> 
> However even with reasoning it is fairly easy to ask in SPARQL for
> 
> SELECT ?attribute, ?value WHERE {
>  ?entity prov:characterizedBy ?char .
>  ?char ?attribute ?value .
> }


or even easier:

SELECT ?attribute ?value 
WHERE {
   ?entity a prov:Entity;
             ?attribute ?value .
}

or, if we go with this "RDF properties are too general" view,

SELECT ?attribute ?value 
WHERE {
   ?entity a prov:Entity;
             ?attribute ?value .
    ?attribute rdfs:subPropertyOf prov:characterizingProperty . # but why? let's just use what RDF already gave us.
}




> 
> (this ignores ?entity ?attribute ?value)
> 
> 
>>> :car :characterizedBy :colour, :owner .
>> Yes, I guess that will work as well.
> 
> And here we (should) also have then :car :colour :blue etc. directly
> on the entity.
> 
> This proposal specifically defines that only those property types
> listed, and only directly (not their object's properties), are
> included in the characterisation.  (To do deeper characterization,
> perhaps the objects referred to can be made prov:Entity and have their
> own characterisations).
> 
> OWL-wise I guess also sub-properties of these are included - but this
> is still much less complicated than supporting properties inherited by
> class membership, inverse properties, etc. So eve is *not* part of the
> characterization here (but it could in theory be reasoned to be so in
> the first example).
> 
> In SPARQL this is almost identical to above:
> 
> SELECT ?attribute, ?value WHERE {
>  ?entity prov:characterizedBy ?attribute .
>  ?entity ?attribute ?value .
> }
> 
> 
> As a side note, one thing this proposal does not capture is partial
> characterization, if the property might have multiple values, but only
> a few of those are part of characterizing the entity. For instance:
> 
> :car :owner :luc, :lucsFriend
> 
> now we can't say that the entity is characterised by being owned by
> luc and any other owner

it just did say that. :lucsFriend could be :luc or <http://tw.rpi.edu/instances/TimLebo> .


> - :lucsFriend would implicitly be part of the
> characterization of the entity.


Agreed. But how does that prevent what you think we can't say ("being owned by luc and any other owner")?

> Remember these attribute values could
> come from anywhere due to the open world assumption, although I do
> guess we are assuming scoping by named graphs/resources to capture
> what an asserter has included in the provenance.

I don't think we need to assume named graph scoping. We have the indirection with prov:Entity already and these entities are being grouped by Accounts - so they can float around in the Big Graph and nothing will break.


> 
> 
>>> :car :characterizedBy [ :colour, :owner ] .
> 
> *Caugh*, here is the corrected version, as N3 syntax for lists is ():
> 
> :car prov:characterizedBy ( :colour, :owner ) .


Oh my. Reinventing OWL on top of reinventing RDF?

> 
> 
> This one is unfortunately tricky in SPARQL as rdf:List are really
> unpacked linked nodes and we don't know the position of the attribute.


(Although I disagree with the premies)
Why would order matter?


> 
> 
> 
>> This also should work. One question Stian, at the level of the OWL ontology,
>> will we need to define any class and/or object properties to allow for this
>> third option?
> 
> Yes, with some trickery this might work:
> 
> 


Or just prov:characterizingProperty (or not and just using RDF properties).


-Tim Lebo


> prov:characterizedBy a owl:ObjectProperty, owl:FunctionalProperty ;
>    rdfs:domain prov:Entity ;
>    rdfs:range prov:CharacterizedBy .
> 
> prov:CharacterizedProperty a owl:Class ;
>    rdfs:subClassOf rdf:Property .
> 
> 
> prov:CharacterizedBy a owl:Class ;
>    rdfs:subClassOf
>        rdf:List,
>        [
>             a owl:Restriction;
>             owl:onProperty rdf:first;
>             owl:allValuesFrom prov:CharacterizedProperty
>            ],
>        [
>             a owl:Restriction;
>             owl:onProperty rdf:last;
>             owl:allValuesFrom [
>                owl:unionOf ( prov:CharacterizedBy rdf:nil)
>               ]
>        ]
> 
> 
> -- 
> Stian Soiland-Reyes, myGrid team
> School of Computer Science
> The University of Manchester
> 
> 
Received on Friday, 16 September 2011 22:49:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 13:06:41 GMT