[Gzz-commits] fenfire/docs/pegboard/vocabprocess--tjl peg.rst

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/fenfire
Module name:    fenfire
Changes by:     Tuomas J. Lukka <address@hidden>        03/05/12 08:55:38

Modified files:
        docs/pegboard/vocabprocess--tjl: peg.rst 

Log message:
        fixpeg

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/fenfire/fenfire/docs/pegboard/vocabprocess--tjl/peg.rst.diff?tr1=1.5&tr2=1.6&r1=text&r2=text

Patches:
Index: fenfire/docs/pegboard/vocabprocess--tjl/peg.rst
diff -u fenfire/docs/pegboard/vocabprocess--tjl/peg.rst:1.5 
fenfire/docs/pegboard/vocabprocess--tjl/peg.rst:1.6
--- fenfire/docs/pegboard/vocabprocess--tjl/peg.rst:1.5 Mon May 12 06:40:54 2003
+++ fenfire/docs/pegboard/vocabprocess--tjl/peg.rst     Mon May 12 08:55:38 2003
@@ -3,8 +3,8 @@
 =============================================================
 
 :Author:   Tuomas J. Lukka
-:Last-Modified: $Date: 2003/05/12 10:40:54 $
-:Revision: $Revision: 1.5 $
+:Last-Modified: $Date: 2003/05/12 12:55:38 $
+:Revision: $Revision: 1.6 $
 :Status:   Current
 
 It seems that vocabularies are easy to create but difficult
@@ -47,16 +47,20 @@
 
 - Should we merge spatial into canvas2d?
 
-    RESOLVED: Yes. Can you give me an example where spatial would
+    RESOLVED: Yes. Spatial will most likely not 
     be used without canvas2d?  The point is, the x and y coordinates
-    are pretty specific to canvases, and while I see containment + x +
-    y as a reasonable structure orthogonal to everything else, separating
-    containnment and x and y to me does not make sense.
+    are pretty specific to canvases, and while containment + x +
+    y is a reasonable structure orthogonal to everything else, 
+    separating containnment and x and y to does not seem make sense.
 
     Also, if it's spatial, it should also have z ;)
 
-    It would be acceptable to have Spatial be a *superclass* of Canvas2D, 
-    but this might not be worth the trouble.
+    It would be acceptable to have Spatial be a *superclass* 
+    of Canvas2D, but this is probably not worth the trouble.
+
+    Another point: the x and y are the *default* coordinate
+    attributes, see the discussion on extensibility
+    (to be done later) in javadoc.
 
 - What should be the namespace prefix? ``vocabulary``,
   ``rdf`` or ``terms`` or ``rdfv``?
@@ -110,6 +114,14 @@
 
     RESOLVED: Not yet. A further PEG will address this issue.
 
+- Should the URI names contain the .HTML suffix?
+
+    RESOLVED: No.  It serves zero purpose (except allowing the
+    website admin to be lazy) and makes it unintuitive to serve non-HTML
+    representations of the namespace (such as RDF Schema).
+
+
+
 Changes
 =======
 
@@ -121,16 +133,18 @@
 This means that the code implementing access using the vocab. of a certain
 class should be relatively independent of the other vocabularies.
 
-For instance, a spatial canvas is a reasonable unit: there is a canvas, it 
contains
-certain nodes at certain locations. However, the PP links (now dLinks) or xu 
links (now CLinks)
-between different canvases do not actually belong in the same place; they are 
orthogonal
-to the spatial structure.
+For instance, a spatial canvas is a reasonable unit: there is a canvas,
+it contains certain nodes at certain locations. However, the PP links
+(now dLinks) or xu links (now CLinks) between different canvases do not
+actually belong in the same place; they are orthogonal to the spatial
+structure.
 
 Currently, our code is pretty well along this structure: CanvasView2D takes
 care of the spatial canvas, and PPConnector (name needs to change) of the 
dLinks.
 
-The more independent we can make the codes, the easier it will be to slot in 
new
-behaviours.
+The more independent we can make the codes using the different
+orthogonal structural pieces, the easier it will be to
+slot in new behaviours.
 
 Overall changes 
 ---------------
@@ -141,13 +155,14 @@
 
 Freeze ``org.fenfire.vocab``. Changes only through PEG process.
 
-Change the prefix ``http://fenfire.org/vocabulary/``
-to ``http://fenfire.org/rdf-v/``.
-After the prefix, each namespace shall contain the year and month it was 
originally
-defined in, in the form
-``2003/05/``. After that, the name of the namespace, lowercase, with .html 
-suffix.
+Change the prefix ``http://fenfire.org/vocabulary/`` to
+``http://fenfire.org/rdf-v/``.  After the prefix, each namespace
+shall contain the year and month it was originally defined in,
+in the form ``2003/05/``. After that, the name of the namespace,
+lowercase.  Finally, the name of the 
+resource is specified using ``#`` and the resource name.
 So, for instance, FF.content would be
-``http://fenfire.org/rdf-v/2003/05/fenfire.html#content``.
+``http://fenfire.org/rdf-v/2003/05/fenfire#content``.
 
 
 All new words define without PEG go into org.fenfire.vocab.lava
@@ -156,7 +171,9 @@
 
 All entries in vocabulary classes shall have their **official**
 definitions there, in their javadocs. There shall be no members
-or classes without good documentation.
+or classes without good documentation. This is mandatory for
+offical vocabularies and **strongly** recommended for lava
+vocabularies.
 
 Vocabulary changes, prior to freezing
 -------------------------------------
@@ -173,7 +190,8 @@
 
 Then, we have left ``xuLinkFrom``, ``xuLinkTo``, ``xuLinkType``.
 We should probably avoid 'xu' in the permanent names,
-just in case. These should be moved to CLINK.CLink, CLINK.cLinkFrom,
+just in case. These should be moved to CLINK (defined below)
+as CLINK.CLink, CLINK.cLinkFrom,
 CLINK.cLinkTo for clink, "content link", a term Ted at some point used.
 
 FF
@@ -202,7 +220,7 @@
     /** RDF Vocabulary of content links.
      */
     public class FF {
-       /** The RDF type for content links. An node which is a content link
+       /** The RDF class for content links. An node which is a content link
         * must have both the cLinkFrom and cLinkTo properties.
         */
        static public Object CLink;
@@ -228,8 +246,8 @@
     /** RDF Vocabulary of 2D spatial canvases.
      */
     public class CANVAS2D {
-       /** The RDF type of spatial 2D canvases.
-        * Canvases contain (with the "contains" property
+       /** The RDF class of spatial 2D canvases.
+        * Canvases contain (with the "contains" property)
         * nodes, which shall have the "x" and "y" properties.
         */
        static public Object Canvas2D;
@@ -239,7 +257,7 @@
        static public Object contains;
        /** The x and y coordinates of a node on a canvas.
         * (node, x, literal), where the literal is parseable
-        * as a float. 
+        * as a floating-point number (similar to Java doubles). 
         * Note that these are the <em>default</em> coordinate
         * properties: later on, we might make it possible for a Canvas2D
         * to define its own coordinate attributes, which would take
@@ -251,8 +269,9 @@
 PP
 ""
 
-Remove everything except association. Move association to DLINK.
-Remove class. PP is really a special-case user interface for a subset of the 
full
+Remove this class. 
+Move association to DLINK.
+PP is really a special-case user interface for a subset of the full
 fenfire structure, so it's quite reasonable not to include a special 
vocabulary for it.
 
 DLINK
@@ -282,8 +301,9 @@
      */
     public class RDF {
 
-       /** The RDF type attribute. A node's type can be declared to be Foo 
-        * by a triple * (node, RDF.type, Foo).
+       /** The RDF type attribute. A node's type can be declared 
+        * to be Foo 
+        * by a triple (node, RDF.type, Foo).
         */
        static public Object type;
     }