--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/model/extensibility.txt	Mon Sep 12 20:50:24 2011 +0100
@@ -0,0 +1,201 @@
+
+
+Extensibility points:
+
+- for entities: a standard attribute (type),  note compatible with definition of attribute since remaining constant during caracterization interval
+
+
+- for process execution: recipe link, built in the definitin of process exectuion
+
+      where you subtype process execution is with recipe link, 
+      it up to the application to define how to encode type
+
+     Note, if requirement comes up, we may expose it as a first-class property.
+
+
+
+
+
+
+- Should everything be annotable
+ 
+
+
+recipe link: need a production
+  is recipe link a uri or identifier
+
+identifier what is it
+
+
+
+
+
+
+- Declaration of namespace in container
+
+- General annotation mechanism for unconstrained name value pairs
+     such as rendering metadata for provenance graphs (eg. label, colour)
+
+  -  WHAT can we annotate?  
+    - annotations are first class citizens, they are an element of the model
+    - can be associated to anything that has an identifier (using standard notation, has annotation)
+         and that includes relations (e.g. wasGeneratedBy) since they have implicitly an identifier
+            (id x id x role)
+    - annotations must have an identifier
+     
+
+e is entity
+  hasAnnotation [ is Annotation
+                  hasName "ex:foo"
+                  hasValue "bar"
+                  hasAnnotation ...
+                  hasAccount ... ]
+
+e is entity
+  ex:foo "bar"
+
+annotation(ann1,[ attr: val, ...])
+hasAnnotation(e1, ann1)
+hasAnnotation(e2, ann1)
+
+what's the difference between attributes and annotations
+
+- Colour as annotation is not same as color as attribute
+
+- attributes are intrisic part of characterization
+  annotations, are application dependent, and do not help characterize entities
+   colour as attribyte characterizes a car
+   colour as annotation is application dependent, and may be used for instance to render the graph.
+
+-> types: attributes of entities,
+          
+  for processexecutoin, st, et, type, rl, are standard attributes (in the same sense as for entities)
+
+   needs to adopt same syntax as entities.
+
+
+
+In 8.2.1. say that type is a reserved name for attributes
+Need a section for standard attributes
+
+
+processExecution := processExecution ( identifier [, recipe] [, time] [, time] )
+
+processExecution := processExecution ( identifier , [ attribute-values ] )
+
+
+
+ 
+
+   
+----------------------------------------------------------------------
+
+Should role be [attribute-values]
+
+use() ...=use(..., useQualifiers)
+
+useQualifiers= attribute-values
+
+
+A given qualifier must be "unique" for a process execution:
+  Failing to do so, would prevent us from annotating use,generation, derivation
+  or expressing pe-linked-derivation
+
+If you want to annoate an edge or express pe-linked-derivation, qualifiers must be unique.
+
+example of streamTO WRITE
+  x:port 1,  x:pos=1, 
+  x:port 1,  x:pos=2, 
+
+
+prov:role 
+
+
+procedrue: proc:parameterName, proc:parameterType
+
+
+pe-linked-derivation:= wasDerivedFrom ( identifier , identifier [, processExecution , generateQualifier , useQualifier] )
+
+multiple occurrences of type attributes
+
+----------------------------------------------------------------------
+
+- Action Luc: keep on renaming xxx -> xxxExpression
+- Action Luc: replace roles by xxxQualifier  (use/generatedBy)
+    and expand the grammer of those xxxQualifiers
+
+- 
+interoperability: must exchange prov:concept
+
+----------------------------------------------------------------------
+
+
+31: prov-dm, prov-asn
+
+42: ?? no action
+
+43: ?? no action
+
+44: needs aligning to new terminology/grammars
+
+64: solved with qualifers + if ..., then MUST
+
+69: give example of two process executions one paused, the other
+relocated, attribute changing is location, part of the characterization of the PE.
+
+71: closeable
+
+81: 
+     given a scope, 
+     nultiple entity expressions with a same id,
+    they should be understood as taking the union of all attributes (as conformant to grammar)
+     authro=john
+     authro=bar  ->  [authro=bar, authro=john] 
+
+     id
+
+accounts:  
+  - hierarchical nature is useful
+  -   give example e1 isComplementOf e0 should be in 
+     e0 in toplevel account, e1 in lowerlevel account, scope of e0 includes lowevel account
+
+- container is wrapper, namespace declarations, and mul
+            house keekping concept
+            containing multiple accounts, potentially 
+            an index of all accounts
+            all expressions belong to a default account, placed inside a container
+
+            is it named?
+   
+
+   
+
+82: event was introduced in the conceptualisation, but there is no first class expression in the model to represents, annotate them, or associate relationships with them.
+  We should see whether this is enough, or whether we have more requirements
+
+
+
+85: to be closed pending review
+
+86: paolo to do an ER diagram
+
+87: now addressed by the new structure
+
+48: to close
+
+29: ask stephen, can this be closed , see complementOf
+
+50: add some text around wasScheduledAfter, close issue 50 (pending)
+    raise another issue, to ask about wasScheduledAfter
+
+91: locations are optional attributes for entities and process if they characterize them
+    for the duration,
+    alternative they can be expressed an annotation,
+    
+    standard name: location
+    multiple locations are possible
+
+94: yes
+
+
+if role becomes qualifier, should time be encoded in qualifier??