Just typos corrections
authorT Dong Huynh <tdh@ecs.soton.ac.uk>
Tue, 14 Feb 2012 00:08:01 +0000
changeset 1544 2dc386f069dc
parent 1543 78a266e418bf
child 1545 b75d9bcfeb30
Just typos corrections
model/working-copy/towards-wd4.html
--- a/model/working-copy/towards-wd4.html	Mon Feb 13 22:21:40 2012 +0000
+++ b/model/working-copy/towards-wd4.html	Tue Feb 14 00:08:01 2012 +0000
@@ -204,8 +204,8 @@
 whether information is to be trusted, how it should be integrated with
 other diverse information sources, and how to give credit to its
 originators when reusing it.  In an open and inclusive environment
-such as the Web, users find information that is often contradictory or
-questionable: provenance can help those users to make trust judgments.
+such as the Web, where users find information that is often contradictory or
+questionable, provenance can help those users to make trust judgements.
 </p>
 
 
@@ -239,7 +239,7 @@
 
 <p>
 The PROV-DM data model for provenance consists of a set of core
-concepts, and a few common relations, based on these core concepts.  PROV-DM is a domain-agnotisc model, but with clear extensibility points allowing further domain-specific and
+concepts, and a few common relations, based on these core concepts.  PROV-DM is a domain-agnostics model, but with clear extensibility points allowing further domain-specific and
 application-specific extensions to be defined.</p>
 
 <p>This specification intentionally presents the key concepts of the PROV Data Model, without drilling down into all its subtleties.  Using these key concepts, it becomes possible to write useful provenance assertions very quickly, and publish or embed them along side the data they relate to. </p>
@@ -335,7 +335,7 @@
 
 
 <div class="anexample" id="activity-example">
-<p>An activity may be the publishing of a document on the web, sending a twitter message, extracting metadata embedded in a file, or driving a car from Boston to Cambridge, assembling a data set based on a set of measurements, performing a statistical analysis over a data set, sorting news items according to some criteria, running a sparql query over a triple store, and editing a file.</p>
+<p>An activity may be the publishing of a document on the web, sending a twitter message, extracting metadata embedded in a file, or driving a car from Boston to Cambridge, assembling a data set based on a set of measurements, performing a statistical analysis over a data set, sorting news items according to some criteria, running a SPARQL query over a triple store, and editing a file.</p>
 </div>
 
 
@@ -431,7 +431,7 @@
 <p>
 Having found a resource, a user may want to retrieve its
 provenance. For users to decide whether they can place their trust in
-that resource, they may want to analyse its provenance, but also determine
+that resource, they may want to analyze its provenance, but also determine
 who the provenance is attributed to, and when it was
 generated. Hence, from the PROV-DM data model, the provenance is
 regarded as an entity, an AccountEntity, for which provenance can be
@@ -565,7 +565,7 @@
 </ul>
 
 <p>
-We now paraphrase some PROV-DM asssertions, and illustrate them with the PROV-ASN notation, a notation for PROV-DM aimed at human consumption.  Full details of the provenance record can be found <a href="examples/w3c-publication1.prov-asn">here</a>.
+We now paraphrase some PROV-DM assertions, and illustrate them with the PROV-ASN notation, a notation for PROV-DM aimed at human consumption.  Full details of the provenance record can be found <a href="examples/w3c-publication1.prov-asn">here</a>.
 
 <ul>
 <li>There is a technical report, a working draft on the recommendation track (<a href="http://www.w3.org/2005/10/Process-20051014/tr.html#RecsWD">pr:RecsWD</a>), which is regarded as an entity so that we can describe its provenance. Similar descriptions exist for all entities.
@@ -602,10 +602,10 @@
 Provenance descriptions can be <em>illustrated</em> graphically. The illustration is not intended to represent all the details of the model, but it is intended to show the essence of a set of
 provenance statements.  Therefore, it should not be seen as an alternate notation for expressing provenance.</p>
 
-<p>The graphical illustration takes the form of a graph. Entities, activities and agents are represented as nodes, with oval, rectangular, and octogonal shapes, respectively.  Usage,
+<p>The graphical illustration takes the form of a graph. Entities, activities and agents are represented as nodes, with oval, rectangular, and octagonal shapes, respectively.  Usage,
 Generation, Derivation, and Activity Association are represented as directed edges.</p>
 
-<p>Entities are layed out according to the ordering of their generation event.  We endeavor to show time progressing from top to bottom. This means that edges for Usage, Generation and
+<p>Entities are laid out according to the ordering of their generation event.  We endeavor to show time progressing from top to bottom. This means that edges for Usage, Generation and
 Derivation typically point upwards.</p>
 
 
@@ -625,7 +625,7 @@
 </div>
 
 
-<p> This simple example has shown a variety of PROV-DM constructs, such as Entity, Agent, Activity, Usage, Generation, Derivation, and ActivityAssociation. In this example, it happens that all entities were already Web resources, with readily available URIs, which we used. We note that some of the resources are public, whereas others have restricted access: provenance statements only make use of their identifiers. If identifiers do not pre-exist, e.g. for activities, then they can be minted, for instance <span class="name">ex:pub2</span>, occuring in the namespace identified by prefix <span class="name">ex</span>.  We note that the URI scheme developed by W3C is particularly suited for expressing provenance of these reports, since each URI denotes a specific version of a report. It then becomes very easy to relate the various versions, with PROV-DM constructs. </p>
+<p> This simple example has shown a variety of PROV-DM constructs, such as Entity, Agent, Activity, Usage, Generation, Derivation, and ActivityAssociation. In this example, it happens that all entities were already Web resources, with readily available URIs, which we used. We note that some of the resources are public, whereas others have restricted access: provenance statements only make use of their identifiers. If identifiers do not pre-exist, e.g. for activities, then they can be minted, for instance <span class="name">ex:pub2</span>, occurring in the namespace identified by prefix <span class="name">ex</span>.  We note that the URI scheme developed by W3C is particularly suited for expressing provenance of these reports, since each URI denotes a specific version of a report. It then becomes very easy to relate the various versions, with PROV-DM constructs. </p>
 
 
 </section>
@@ -642,7 +642,7 @@
 <li> Several persons are associated with activity <span class="name">ex:edit1</span>, some in an editorial role, some in a contributor's role.</li>
 </ul>
 
-<p>Again, we paraphrase some PROV-DM asssertions, and illustrate them with the PROV-ASN notation.
+<p>Again, we paraphrase some PROV-DM assertions, and illustrate them with the PROV-ASN notation.
 Full details of the provenance record can be found <a href="examples/w3c-publication3.prov-asn">here</a>.</p>
 
 <ul>
@@ -693,7 +693,7 @@
 <section id="section-example-c"> 
 <h3>Attribution of Provenance</h3>
 
-<p>The two previous sections  provide  two different perspectives on the provenance of a technical report. By design, the PROV approach allows for the provenance of a subject to be provided by multiple sources. For users to decide whether they can place their trust in the technical report, they may want to analyse its provenance, but also determine
+<p>The two previous sections  provide  two different perspectives on the provenance of a technical report. By design, the PROV approach allows for the provenance of a subject to be provided by multiple sources. For users to decide whether they can place their trust in the technical report, they may want to analyze its provenance, but also determine
 who the provenance is attributed to, and when it was
 generated, etc. In other words, we need to be able to express the provenance of provenance.</p>
 
@@ -798,7 +798,7 @@
 </pre>
 <p>states the existence of an activity with identifier <span class="name">a1</span>, start time <span class="name">2011-11-16T16:05:00</span>, and end time <span
 class="name">2011-11-16T16:06:00</span>, running on host <span class="name">server.example.org</span>, and of type <span class="name">edit</span>.  The attribute <span class="name">host</span>  is application specific  (declared in some namespace with prefix <span class="name">ex</span>).  The attribute <span
-class="name">type</span> is a reserved attribute of PROV-DM, allowing for subtyping to be expressed.</p>
+class="name">type</span> is a reserved attribute of PROV-DM, allowing for sub-typing to be expressed.</p>
 </div>
 
 
@@ -867,7 +867,7 @@
 
 <p>As provenance descriptions are exchanged between systems, it may be useful to add extra-information to what they are describing. For instance, a "trust service" may add value-judgements about the
 trustworthiness of some of the entities or agents involved. Likewise, an interactive visualization component may want to enrich a set of provenance descriptions with information helping reproduce their
-visual representation. To help with inter-operability, PROV-DM introduces a simple annotation mechanism allowing anythig that is identifiable to be associated with notes.</p>
+visual representation. To help with inter-operability, PROV-DM introduces a simple annotation mechanism allowing anything that is identifiable to be associated with notes.</p>
 
 <p>A <dfn title="dfn-note">note</dfn><span class="withAsn">, noted <span class="name">note(id, [ attr1=val1, ...])</span> in PROV-ASN,</span> contains:</p>
 <ul>
@@ -1108,7 +1108,7 @@
 <ul>
 <li><em>id</em>:  an OPTIONAL identifier identifying the activity end;</li> 
 <li><em>activity</em>: an identifier identifying the ended activity;
-<li><em>agent</em>: an identifier for the agent ending the acitivity;
+<li><em>agent</em>: an identifier for the agent ending the activity;
 <li><em>attributes</em>: an OPTIONAL set of attribute-value pairs describing modalities according to which the agent ended the activity.
 </ul>
 
@@ -1226,7 +1226,7 @@
 is known to have occurred, more than one activities are known to have occurred, or an unknown number of activities have occurred. Likewise, we can consider another axis to cover other
 details (identities, generation, usage, and attributes), with values <em>asserted</em> and <em>not asserted</em>. We can then form a matrix of possible derivations. Out of the six
 possibilities, 
-PROV-DM offers three forms of derivations to cater for five of them, while the remaining one is not meaningful.  The following table summarises names for the three kinds of
+PROV-DM offers three forms of derivations to cater for five of them, while the remaining one is not meaningful.  The following table summarizes names for the three kinds of
 derivation, which we then explain.</p>
 
 <div style="text-align: center;">
@@ -1354,9 +1354,9 @@
 Consider for example three entities:
 </p>
 <ul>
-  <li><span class="name">e1</span> denoting "Bob, the holder of facebook account ABC",
+  <li><span class="name">e1</span> denoting "Bob, the holder of Facebook account ABC",
   
-  <li><span class="name">e2</span> denoting "Bob, the holder of twitter account XYZ",
+  <li><span class="name">e2</span> denoting "Bob, the holder of Twitter account XYZ",
 
   <li><span class="name">e3</span> denoting "Bob, the person".
 </ul>
@@ -1365,7 +1365,7 @@
 
 
 <ol>
-  <li>e1 and e2 refer to Bob in two contexts (as facebook and twitter users, respectively)
+  <li>e1 and e2 refer to Bob in two contexts (as Facebook and Twitter users, respectively)
   <li> both of e1 and e2  are more detailed then than e3.
 </ol>
 
@@ -1390,8 +1390,8 @@
 
 <ul>
 <li><em>id</em>:  an OPTIONAL identifier for the association between the two entities;</li>
-<li><em>specializedEntity</em>: an identifier of the specialised entity;</li>
-<li><em>generalEntity</em>: an identifier of the entity that is being specialised;</li>
+<li><em>specializedEntity</em>: an identifier of the specialized entity;</li>
+<li><em>generalEntity</em>: an identifier of the entity that is being specialized;</li>
 <li><em>attributes</em>: an OPTIONAL set of attribute-value pairs to further describe this relation.</li>
 </ul>
 
@@ -1421,7 +1421,7 @@
 <p>An <dfn title="dfn-annotation">annotation</dfn><span class="withAsn">, written <span class="name">hasAnnotation(id,r,n,attrs)</span> in PROV-ASN,</span> has the following constituents:</p>
 <ul>
 <li><em>id</em>:  an OPTIONAL identifier for this relation;</li>
-<li><em>something</em>: the identifier of someting being annnotated;</li>
+<li><em>something</em>: the identifier of something being annotated;</li>
 <li><em>note</em>: an identifier of a note;</li>
 <li><em>attributes</em>: an OPTIONAL set of attribute-value pairs to further describe this annotation.</li>
 </ul>
@@ -1473,7 +1473,7 @@
 
 <p>A <dfn id="dfn-namespaceDeclaration">namespace declaration</dfn> consists of a binding between a prefix and a namespace. Every qualified name with this prefix in the scope of this
 declaration refers to this namespace. 
-A <dfn id="dfn-defaultNamespaceDeclaration">default namespace declaration</dfn> consists of a namespace. Every unprefixed qualified name in the scope of this default namespace declaration
+A <dfn id="dfn-defaultNamespaceDeclaration">default namespace declaration</dfn> consists of a namespace. Every un-prefixed qualified name in the scope of this default namespace declaration
 refers to this namespace.</p>
 
 <p>The PROV-DM namespace is <span class="name">http://www.w3.org/ns/prov-dm/</span> (TBC).</p>
@@ -1904,7 +1904,7 @@
   <li><span class="name">EmptyCollection</span> denotes an empty collection.
 </ul>
 
-The following relations relate a collection <span class="name">c1</span> with a collection <span class="name">c2</span> obtainted after adding or removing a new pair to (resp. from) <span class="name">c1</span>:
+The following relations relate a collection <span class="name">c1</span> with a collection <span class="name">c2</span> obtained after adding or removing a new pair to (resp. from) <span class="name">c1</span>:
 
 <ul>
   <li>Insertion relation <span class="name">CollectionAfterInsertion(c2, c1, k, v)</span> states that  <span class="name">c2</span> is the state of the collection
@@ -2073,7 +2073,7 @@
 
 <li>Namespaces allow attributes and names to be qualified. </li>
 
-<li>Subtyping of elements and relations is allowed by means of the reserved attribute <span class="name">type</span>.</li>
+<li>Sub-typing of elements and relations is allowed by means of the reserved attribute <span class="name">type</span>.</li>
 
 <li>Domain specific values can be expressed by means of typed literals. </li>
 </ul>
@@ -2122,7 +2122,7 @@
 <li> relying on specific serializations to name bundles of descriptions;</li>
 <li> using the idea of a service that is capable of associating provenance descriptions to whom they are attributed to.</li>
 </ul>
-<p>Even though a mechanism for packaging up provenance descriptions and naming them is not part of PROV-DM, the idea of a bundle of descriptions is crucial to the PROV approach. Indeed, it allows multiple provenance perspectives to be provided for a given entity. It is also the mechanism by which provenance of provenance can be expressed. Such a named blundle is being referred to as an <dfn>account</dfn> and is regarded as an <a title="concept-accountEntity">AccountEntity</a> so that its provenance can be expressed.   The notion of account is specified in the companion specification [[PROV-DM-CONSTRAINTS]], as well as constraint that  <dfn>structurally well-formed</dfn> descriptions are expected to satisfy.</p>
+<p>Even though a mechanism for packaging up provenance descriptions and naming them is not part of PROV-DM, the idea of a bundle of descriptions is crucial to the PROV approach. Indeed, it allows multiple provenance perspectives to be provided for a given entity. It is also the mechanism by which provenance of provenance can be expressed. Such a named bundle is being referred to as an <dfn>account</dfn> and is regarded as an <a title="concept-accountEntity">AccountEntity</a> so that its provenance can be expressed.   The notion of account is specified in the companion specification [[PROV-DM-CONSTRAINTS]], as well as constraint that  <dfn>structurally well-formed</dfn> descriptions are expected to satisfy.</p>
 </li>