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

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


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 .

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


I think it would simplify things if the characterisation properties is
only one level down. 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)
               ]
        ]


-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Friday, 16 September 2011 14:07:03 UTC