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

On 09/09/2011 02:32 PM, Stian Soiland-Reyes wrote:
> On Thu, Sep 8, 2011 at 17:31, Luc Moreau<L.Moreau@ecs.soton.ac.uk>  wrote:
>
>
>    
>> 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.
>>      
> *Warning* - another long Stian email.
>    

Indeed very long ;-)
Thanks for trying to encode the example.
>
> RDF-wise we I think we would need to express these attributes outside
> the regular graph.
>    

What do you mean by regular?

I tend to talk about application data, and if we make the application 
provenance-aware, we also have provenance data.
Is your regular graph, the application data graph?
>
> For instance with anonymous nodes and prov:wasCharacterisedBy :
>    

Is wasCharacterisedBy a relation that has been previously defined by the 
WG or is it your proposal here?

> :e1 a prov:Entity ;
>    prov:wasCharacterisedBy [
>       car:company "Toyota" ;
>         car:model "Corolla" ;
>        car:identification "1a"
>    ] .
>
> :e2 a prov:Entity ;
>    prov:wasCharacterisedBy [
>       car:company "Toyota" ;
>       car:model "Corolla" ;
>       car:identification "1a" ;
>       car:owner "tom"
>    ] .
>
> :e3 a prov:Entity ;
>    prov:wasCharacterisedBy [
>       car:company "Toyota" ;
>       car:model "Corolla" ;
>       car:identification "1a" ;
>       car:owner "luc"
>    ] .
>    

OK, I think this would encode the atttributes of an entity. We
need to make sure that there is only one wasCharacterizedBy per entity.
> # Other statements, not part of prov:wasCharacterisedBy
> :e1 car:hasColor "blue" .
> :e2 car:hasColor "blue" .
> :e3 car:hasColor "blue" .
>
>
>
> If prov:wasCharacterisedBy is a subproperty of owl:sameAs you could
> with just a tiny bit of reasoning find
>    :e3 car:owner "luc";
> however this raises lots of nasty questions about what attributes are
> part of the characterisation, with reasoning enabled you would just
> find
>   :e3 prov:wasCharacterisedBy :e3 and every attribute of :e3.
>
> Probably more sensible is to make prov:wasCharacterisedBy a
> subproperty of prov:wasComplementOf as that would be true anyway.
> (right?)
>
>
>    

Hhm, really?

> But what if you are characterised by something with richer attributes?
> The Abstract Provenance notation allows only flat attributes:
>
> entity := entity ( identifier , [ attribute-values ] )
> attribute-values := attribute-value |attribute-value , attribute-values
> attribute-value := attribute : Literal
>
> so:
>
>    entity(e3, [ owner: [ name: "Luc", address: "Southampton" ] ])
>
> would not be allowed. It says Literal, so not even URIs?
>
>    entity(e3, [ owner:<http://id.ecs.soton.ac.uk/person/391>  ])
>
>
>
>    

I think this part of the spec needs to be discussed here. It's related
to the question of domain specific data.

I thought about Literals in this sense 
http://www.w3.org/TR/owl2-syntax/#Literals
So, it can be
typedLiteral := lexicalForm '^^' Datatype

and you should be able to encode uris, with type xsd:anyURI
and in general any complex structure.



> In RDF this would sound like an arbitrary restriction, in theory in
> RDF you could simply do:
>
>
> :e3 a prov:Entity ;
>    prov:wasCharacterisedBy [
>       car:company "Toyota" ;
>       car:model "Corolla" ;
>       car:identification "1a" ;
>       car:owner [
>         foaf:name "Luc Moreau" ;
>         foaf:based_near "Southampton"
>       ]
>    ] .
>
> However this causes problems the moment you want to use URIs. If you
> said simply
>    car:owner<http://id.ecs.soton.ac.uk/person/391>
> then we can't say anything more about
> <http://id.ecs.soton.ac.uk/person/391>  within this 'was characterised
> by'.
>
> If I did
>
>    car:owner [
>         owl:sameAs<http://id.ecs.soton.ac.uk/person/391>  ;
>         foaf:name "Luc Moreau" ;
>         foaf:based_near "Southampton"
>    ]
>
> then that raises the sameAs issues as above.
>
>
> Named graphs would allow you to declare multiple resources within the
> characterisation. In TriG format:
>
> {
>    :e1 a prov:Entity ;
>      prov:characterisedBy :e1Attrs ;
>      car:hasColor "blue" .
>
>    :e2 a prov:Entity ;
>      prov:characterisedBy :e1Attrs, :e2Attrs ;
>      car:hasColor "blue" .
>
>    :e3 a prov:Entity ;
>      prov:characterisedBy :e1Attrs, :e3Attrs ;
>      car:hasColor "blue" .
> }
>
> :e1Attrs {
>    :e1 car:company "Toyota" ;
>         car:model "Corolla" ;
>        car:identification "1a" .
> }
>
> :e2Attrs {
>    :e1 car:owner "tom" .
> }
> :e3Attrs {
>    :e1 car:owner<http://id.ecs.soton.ac.uk/person/391>  .
>    <http://id.ecs.soton.ac.uk/person/391>  foaf:name "Luc Moreau" ;
>         foaf:based_near "Southampton" .
> }
>    

What is interesting about named graphs here, is that they "freezed" the 
set of
attributes we want to assert for a given entity.
> One advantage of nested graphs is that it would be fairly easy to
> query across all graphs to find both characterised and 'other'
> properties of the car. Also above I allowed multiple graphs in
> prov:characterisedBy to reuse common attributes.
>
>
> I'm not sure if I like this named graph approach, because it seems to
> say that everything in the characterisation graph must be true to be
> able to identify :e1, and it's easy to include too much information
> within the graph which is just auxiliary information.
>
>
> Above, the car is owned by<http://id.ecs.soton.ac.uk/person/391>
> called "Luc Moreau", based in Southampton - so if elsewhere
> <http://id.ecs.soton.ac.uk/person/391>  had the name "Professor Luc
> Moreau" and was based in Boston, then that person would not
> necessarily be the owner of the car, even if he has the same URI.
> Perhaps this is good? After all the asserter did include those details
> inside the prov:characterisedBy graph instead of in the default graph,
> so they must be important.
>
>
> (As always) I've argued with myself here, and I think that although
> nested descriptions would be nice, it opens up a can of worms, and we
> should keep the attributes flat, and rather say that you should
> describe nested attributes by introducing a new prov:Entity with its
> own characterisation:
>
>
> :e3 a prov:Entity ;
>    prov:wasCharacterisedBy [
>       car:company "Toyota" ;
>       car:model "Corolla" ;
>       car:identification "1a" ;
>       car:owner :luc
>    ] .
>
> :luc a prov:Entity;
>    prov:wasCharacterisedBy [
>         foaf:name "Luc Moreau" ;
>         foaf:based_near "Southampton"
> ] .
>
>
> Luc, note that I only used your foaf-stuff as examples here, I'm not
> suggesting  you stop owning the car if you move out of Southampton!
> But this would be a good way to talk about narrow compliments such as
> "Luc as the professor teaching subject 101 in 2011 at Southampton
> University"
>    

;-)

Cheers,
Luc
>
>    

-- 
Professor Luc Moreau
Electronics and Computer Science   tel:   +44 23 8059 4487
University of Southampton          fax:   +44 23 8059 2865
Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm

Received on Friday, 9 September 2011 15:37:53 UTC