init person example and added Turtle and 2119 refs
authorMichael Hausenblas http://sw-app.org/mic.xhtml#i
Sun, 29 Jan 2012 12:52:24 +0000
changeset 37 571f4cd6debb
parent 36 0700dd6b5b49
child 38 29289c66c9cf
init person example and added Turtle and 2119 refs
people/index.html
--- a/people/index.html	Sun Jan 29 12:29:49 2012 +0000
+++ b/people/index.html	Sun Jan 29 12:52:24 2012 +0000
@@ -27,9 +27,8 @@
 
 <section class="introductory">
 <h2>Scope</h2>
-
 <p>
-This document is aimed at people who are familiar with RDF schemata. We assume that the reader wants to represent some source data in RDF and hence is looking for an interoperable way to describe people.
+This document is aimed at people who are familiar with RDF schemata. We assume that the reader wants to represent some source data in RDF and hence is looking for an interoperable way to describe people and their relationships to other entities such as organisations, projects, etc.
 </p>
 </section>
 
@@ -48,14 +47,21 @@
 </pre>
 <p class="editorsnote">@@TODO: link to the definition of source data in the <a href="https://dvcs.w3.org/hg/gld/raw-file/default/bp/index.html">BP document</a></p>
 <p>Note: if you're not familiar with people's names throughout the world, you might want to read the <a href="http://www.w3.org/International/questions/qa-personal-names" title="Personal names around the world">personal names around the world</a> article provided by the W3C Internationalization (I18n) Activity.</p>
-<div class="fig"><img src="img/people-example.png" alt="GLD people example" /><div>A visual representation of the walkthrough example as a graph (<a href="img/people-example-big.png">big version</a>).</div>
+<div class="fig"><img src="img/people-example.png" alt="GLD people example" /><div>A visual representation of the walkthrough example as a graph (<a href="img/people-example-big.png">big version</a>).</div></div>
+<p>Note that RDF serialisations examples in this document are written in the Turtle [[TURTLE]] syntax.</p>
+<p>The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in RFC 2119 [[!RFC2119]].
 </section>
 
 <section>
 <h2 id="characteristics">What is a person?</h2>
 <p>The core concept we are dealing with in this document is that of a person. A <dfn>person</dfn> in the context of this specification is defined as an entity of type <code><a href="http://xmlns.com/foaf/spec/#term_Person" title="FOAF Vocabulary Specification">foaf:Person</a></code>.</p>
-<p>If only the person's name is known <code><a href="http://xmlns.com/foaf/spec/#term_name" title="FOAF Vocabulary Specification">foaf:name</a></code> MUST be used. How to provide further details about a person, such as an address, is specified in section <a href="#relations-to-contact-info">relating a person to a contact information</a>.</p>
+<p>If only the person's name is known <code><a href="http://xmlns.com/foaf/spec/#term_name" title="FOAF Vocabulary Specification">foaf:name</a></code> MUST be used.</p>
+<pre class='example'>
+ &lt;http://data.sccgov.org/people/björkg&gt; rdf:type foaf:Person ;
+                                        foaf:name "Björk Guðmundsdóttir" .
+</pre>
 <p class="editorsnote">@@TODO: describe a person's fundamental characteristics (@@TODO: evaluate ISA <a href="http://joinup.ec.europa.eu/asset/core_person/description">Core Person Vocabulary</a>).</p>
+<p>How to provide further details about a person, such as an address, is specified in section <a href="#relations-to-contact-info">relating a person to a contact information</a>.
 <div class="practice">
 	<p><span id="sample-practice" class="practicelab">Deriving domain-specific person types</span></p>
 	<p class="practicedesc">One sometimes finds specialisations of a person in a domain, for example, in the legal domain there is a distinction made between a natural person and a legal person. In such a case one should, in addition to the domain-specific type (e.g., <code>legal:NaturalPerson</code>) explicitly set the type <code>foaf:Person</code> in order to increase interoperability. This also allow systems that do not perform reasoning, for example, plain SPARQL processors to benefit from it. <a href="http://answers.semanticweb.com/questions/13715/owl-subclassing-vs-new-properties-for-existing-classes" title="OWL subclassing vs new properties for existing classes - ANSWERS">Read more ...</a></p>