merged with tip; adding stub for wasDerivedFrom component.
authorTim L <lebot@rpi.edu>
Thu, 06 Oct 2011 09:04:38 -0400
changeset 555 92ec2cbfc60b
parent 554 7ebab33c11c4 (current diff)
parent 553 4305523cdc28 (diff)
child 556 0491e4906eec
merged with tip; adding stub for wasDerivedFrom component.
--- a/model/ProvenanceModel.html	Thu Oct 06 09:04:02 2011 -0400
+++ b/model/ProvenanceModel.html	Thu Oct 06 09:04:38 2011 -0400
@@ -1962,7 +1962,7 @@
 <li> contains a set of identifiers <span class="name">ids</span> naming all accounts occurring (at any nesting level) in  <span class="name">exprs</span>;</li>
 <li> contains one or more  expressions <span class="name">exprs</span>.</li>
 </ul>
-<p>All the expressions in <span class="name">exprs</span> are implictly wrapped in a default account, scoping all the identifiers they declare directly, and constituting a toplevel account, in the hierarchy of accounts.</p>
+<p>All the expressions in <span class="name">exprs</span> are implictly wrapped in a default account, scoping all the identifiers they declare directly, and constituting a toplevel account, in the hierarchy of accounts.  Consequently, every provenance expression is always expressed in the context of an account, either explicitly in an asserted account, or implicitly in a container's default account.</p>
 
 <p>
 The following container </p>
--- a/model/simon-comments.txt	Thu Oct 06 09:04:02 2011 -0400
+++ b/model/simon-comments.txt	Thu Oct 06 09:04:38 2011 -0400
@@ -319,6 +319,11 @@
 >expression is made accessible as part of an account? I think this
 >would be a good thing for clarity, but it is not explicit in the
 >document (and also differs from OPM).
+
+Added sentence: Consequently, every provenance expression is always
+expressed in the context of an account, either explicitly in an
+asserted account, or implicitly in a container's default account.
+
 >
 >Section 5.5.1:
 >(C) I agree with the first note. If it is mandatory to say something
@@ -326,33 +331,62 @@
 >mandatory at all. The "mandatory" thing seems to be just saying
 >something about the ASN, and so is irrelevant as the ASN is just there
 >to make the model concrete and readable.
+
+TODO: should we change to MAY contain a qualifier. A qualifier is a non empty sequence ...
+
 >
 >Sec 5.5.4:
 >(C) Second note: Wouldn't this mean that either account IDs or entity
 >IDs can never be URIs, as a sequence of URIs would itself not be a
 >URI? If so, that seems to make RDF serialisation difficult to achieve.
+
+TODO.
+
+Why do we need to have a URI for a qualified identifier?
+
+Why would this make serialization to RDF difficult. We are proposing for
+a qualified identifier to be only usable in wasComplementOf.
+
+
 >
 >Sec 5.5.6:
 >(C) I don't see the connection between the section's introductory text
 >and the content of the subsections.
+
+TODO. It's unclear where this content should go.
+
 >
 >Sec 5.7.1:
 >(C) I think this section needs something introductory to say why it is
 >relevant to the data model, i.e. what has it to do with provenance,
 >why is it useful in the context of provenance, why is it standardised
 >rather than application-specific?
+
+TODO.(now 7.1)
+
 >(C) If my record of what occurred does not start with an empty
 >container, but one with contents, how do I say that the elements are
 >part of the container? Do I have to model this as a series of
 >wasAddedTo links, even if I know nothing about how the elements were
 >added? Or is it out of scope of the standard?
+
+
+TODO: macro expand ...
+
 >
 >Sec 5.7.2:
 >(C) I don't see how wasQuoteOf is a sub-relation of wasRevisionOf, or
 >wasAttributedTo a sub-relation of wasEventuallyDerivedFrom, when the
 >super-relations do not contain reference to any agents but the
 >sub-relations do. What does it mean?
+
+TODO: all section needs updating.
+
+
 >(T) Last sentence of 5.7.2.2: "wasQuoteOf" should be "wasAttributedTo"
+
+TODO
+
 >
 >Thanks,
 >Simon