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

On Fri, Sep 9, 2011 at 16:37, Luc Moreau <L.Moreau@ecs.soton.ac.uk> wrote:

>> RDF-wise we I think we would need to express these attributes outside
>> the regular graph.
> What do you mean by regular?

I meant the RDF graph that the the assertions from the provenance
account/container have been serialised in. (We have assumed one graph
per account/container to avoid stating everything with reification).
Those graphs could be separate provenance resources on the web, or
part of a named graph serialisation.


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

No, it's the provenance 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?

Had to make it up! Sorry for not clarifying that. It might be a
construct we need only in the ontology, unless we need to change the
model to have the characterisation separate as well.



> OK, I think this would encode the atttributes of an entity. We
> need to make sure that there is only one wasCharacterizedBy per entity.

I agree, that would make it like a primary key and solve many problems
as the anonymous graph can't be extended (except through owl:sameAs
which we then probably should not use).



>> Probably more sensible is to make prov:wasCharacterisedBy a
>> subproperty of prov:wasComplementOf as that would be true anyway.
>> (right?)
> Hhm, really?

Perhaps not - if we assume that anything stated about within :e1
wasCharacterisedBy is also true directly for :e1, and we also make the
range of
wasCharacterisedBy be an Entity which is characterised by itself (what
else?), then :e1 is a complement of the anonymous node, as it has all
the same characterised attributes locked down. But perhaps that's not
very useful - why would we want the characterisation to be an entity?



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

What about the attribute names? Would it be reasonable to assume that
any URI would do, and that they are data/object properties in RDF?
(Would reasoning on those be allowed, say Simon brings in some
subproperties?)

>From the model's definition we could just RDFize it as a collection of
key-value pairs - but I don't think that would be as useful as using
regular properties. It would however be useful in formats like XML and
JSON.

Key-values in RDF/N3 (Using prov:hadAttributes instead of
prov:wasCharacterisedBy):

:e1 a prov:Entity ;
  prov:hadAttributes (
    [  prov:attributeName "company";
       prov:attributeValue "Toyota" ],
    [  prov:attributeName "model";
       prov:attributeValue "Corolla" ],
    [  prov:attributeName "identification";
       prov:attributeValue "1a" ]
  ) .

or JSON:

{ "entities": {
  "e1": { "company": "Toyota", "model": "Corolla", "identification": "1a" }
  "e2": { .. }
  }
}

This raises questions about namespacing, as these keys are used for
characterising things.


> What is interesting about named graphs here, is that they "freezed" the set
> of attributes we want to assert for a given entity.

Yes, and you could tell if two entities are describing the same thing
by ensuring both graphs are equivalent. (something for the RDF WG - I
believe this is already formalised). I am however the named graph
could be misunderstood as "Snapshot of everything true about the
entity when making the provenance".


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

Received on Friday, 9 September 2011 16:25:49 UTC