Re: PROV-ISSUE-229 (Refactor-and-sub-edit): Document would benefit from refactoring and editing [prov-dm]

On Tue, Jan 31, 2012 at 12:07, Luc Moreau <> wrote:
> What do you mean, avoid one item in a bullet list such as
> "attributes: an optional set of attribute-value pairs [ attr1=val1, ...],
> representing this entity's situation in the world."

I'll let Graham defend his 'bloated' argument. ;-)

Here's an example from Activity record:

> If start and end times are known, they are expressed as attributes of an activity, where the interpretation of attribute in the context of an activity record is the same as the interpretation of attribute for entity record: an activity record's attribute remains constant for the duration of the activity it represents. Further characteristics of the activity in the world can be represented by other attribute-value pairs, which must also remain unchanged during the activity duration.

(This is confusing.. are they attributes or not? Why does not the
syntax reflect this? What are the attribute keys?)

> attributes: an optional set of attribute-value pairs [ attr1=val1, ...], representing other attributes of this activity that hold for its whole duration.

> The attribute host is application specific, but must hold for the duration of activity. The attribute type is a reserved attribute of PROV-DM, allowing for subtyping to be expressed.

So I agree that it's not particularly verbose, but it's still
"scattered around" but pretty much doing the same thing. A few places
there are specialisations like saying what prov:role or prov:type
might mean here, but overall the attributes is a general way to attach
custom statements to the provenance assertions.

For instance, I can choose to attach attribute-values to both agent(a)
and entity(a) - but is there a semantic difference? Are the attributes
to be thought of as attributes on the relation between a and the type
Agent, or just attributes right on a?

I get the feeling that the attributes are well-meant and should in
theory support open-world extensions in PROV-O, but in reality
allowing attributes in every relation means all of them 'explode' to
N-ary relationships that become quite heavyweight. Now that's not just
a problem with RDF, you would face similar constraints in JSON and
XML. (XML attributes would not be able to do the job because they
would loose the typing)

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

Received on Tuesday, 31 January 2012 13:46:31 UTC