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

On 16/09/2011 15:06, 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).
>
>
> What I meant was that if you have:
>
> :entity :characterizedBy :entityAttrs
>
> :entityAttrs dc:creator "Khalid";
>      :colour :blue .
>
> would it then also be true that:
>
> :entity dc:creator "Khalid";
>      :colour :blue .
> ?
I don't think this was in the requirement stated by Luc, i.e., overlap 
between the properties that are used to characterize the entity from the 
asserter point of view, and the properties that were attached to the 
entity by, e.g., a third party. That said, I think it is a legitimate 
question, which we can actually break down into the following two questions:

1- Can the same property be used to characterize an entity, i.e., 
associated to :entityAttrs in the above example, and associated to the 
entity itself :entity?

2- If so, should the two properties have the same value (object)?

Personally, I am struggling to find a good example of in which the same 
property *need to be* associated with both :entityAttrs and :entity.

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

Ok. I am not sure either if this kind of constraint can be enforced in OWL.
>
>
>>> 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?

They need to be properties that characterize the entity from the 
observer (asserter) point of view.
>
> This is the Luc-in-Southampton-problem:
>
> :car a prov:Entity ;
>      prov:characterizedBy :carCharacter.
>
> :carCharacter :owner<http://example.com/luc>  ;
>      :colour blue .
>
> <http://example.com/luc>  foaf:based_near :Southampton .
>
>
> now - if<http://example.com/luc>  (who is not declared as an
> prov:Entity here) moves to Oxford, would he then still be the owner of
> the :car by this characterization?

If I get the notion of entity defined in the conceptual model, when you 
modify the location of Luc, which is a property that is used to 
characterize the entity, you are creating a new entity. But your 
question make sense. In the examples we have in the conceptual model so 
far, all attributes that characterize an entity are alphanumeric 
attributes. I don't know if we will need to extend the definition to 
cater for attributes that are complex, in which case, we need to define 
what it means that the value of such attributes is modified.


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

Yes, I agree.

Khalid

> 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 .
> }
>
> (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 - :lucsFriend would implicitly be part of the
> characterization of the entity. 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.
>
>
>>> :car :characterizedBy [ :colour, :owner ] .
> *Caugh*, here is the corrected version, as N3 syntax for lists is ():
>
> :car prov:characterizedBy ( :colour, :owner ) .
>
>
> 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.
>
>
>
>> 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:
>
>
> 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)
>                 ]
>          ]
>
>

Received on Friday, 16 September 2011 16:19:58 UTC