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

Hi Stian,

Response interleaved.

On 01/31/2012 01:45 PM, Stian Soiland-Reyes wrote:
> On Tue, Jan 31, 2012 at 12:07, Luc Moreau<L.Moreau@ecs.soton.ac.uk>  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:
>
> http://dvcs.w3.org/hg/prov/raw-file/tip/model/ProvenanceModel.html#record-Activity
>
>
>    
>> 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?)
>
>
>    

They are, but the requirement of a given value for attributes needs to 
be repeated for entity/activity.
It does not hold for notes.
It trivially holds for generation/usage events because instantenous.
>> attributes: an optional set of attribute-value pairs [ attr1=val1, ...], representing other attributes of this activity that hold for its whole duration.
>>      
>    

As a developer, I would want to see this, because it makes the 
definition of activity record self contained.

Of course, an alternative, is too use inheritance, and indicate there is 
a super class Element
that has attributes ... but then, we suddenly have introduce an extra 
term in the vocabulary: element.

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

This is an example, and I think it's useful for it too be self-contained.
A reader can always hide examples if they want.

> 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.
>
>
>    
Interesting, but prov:role can only appear in some relation.

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

Several relations are n-ary independently of attributes:
- wasAssociatedWith has activity, agent, plan
- actedOnBehalfOf has two agents and an activity
- precise derivations have two entities a generation event and a usage 
event.

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 Tuesday, 31 January 2012 14:10:41 UTC