[MOBY-guts] biomoby commit

[Pieter Neerincs]

pieter
Thu Jan 24 13:33:31 EST 2008
Update of /home/repository/moby/moby-live/Docs/MOBY-S_API
In directory dev.open-bio.org:/tmp/cvs-serv16683

Modified Files:
	DataClassOntology.html ObjectStructure.html 
Log Message:
Synchronised docs with BioMoby 1.0 manuscript: Changed API description of HAS and HASA relationship to allow zero instances of an object.
moby-live/Docs/MOBY-S_API DataClassOntology.html,1.10,1.11 ObjectStructure.html,1.10,1.11
===================================================================
RCS file: /home/repository/moby/moby-live/Docs/MOBY-S_API/DataClassOntology.html,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- /home/repository/moby/moby-live/Docs/MOBY-S_API/DataClassOntology.html	2007/07/31 13:48:30	1.10
+++ /home/repository/moby/moby-live/Docs/MOBY-S_API/DataClassOntology.html	2008/01/24 18:33:31	1.11
@@ -63,7 +63,7 @@
 In the <a href="http://biomoby.org">BioMOBY</a> system, all
 datatypes (Classes) are defined in an ontology, where each node
 represents a named Class, and each arc represents one of two
-relationship types - ISA, or HASA - indicating inheritence or
+relationship types - ISA, or HASA / HAS - indicating inheritence or
 container-relationship respectively.  The root of the Class ontology
 is "Object" as defined above; all data Classes inherit from the
 "Object" Class, and (with the exception of the <a
@@ -103,14 +103,14 @@
 <p>
 These primitive types are special as they are the only cases where the content
 of an element is meant to be interpreted by the client or service.
-New classes <em>MUST NOT</em> inherit from the Primitive Classes.  To obtain
+New classes <em>MUST NOT</em> inherit from the Primitive Classes. To obtain
 content in another class, you must be a <em>container</em> of a
 primitive class. The two relationship types - HASA and HAS - are used
 to indicate container relationships, and the contained object is
 "labelled" using the articleName attribute to indicate its role in
 that object, or more precisely, its semantic relationship with the
-parent object.  HASA indicates that a single instance of the object is
-contained, while HAS indicates that multiple instances of the object
+parent object.  HASA indicates that a maximally a single instance of the object is
+contained, while HAS indicates that zero or more instances of the object
 are contained.
 
 The following RDF triple describes

===================================================================
RCS file: /home/repository/moby/moby-live/Docs/MOBY-S_API/ObjectStructure.html,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- /home/repository/moby/moby-live/Docs/MOBY-S_API/ObjectStructure.html	2007/02/22 16:22:24	1.10
+++ /home/repository/moby/moby-live/Docs/MOBY-S_API/ObjectStructure.html	2008/01/24 18:33:31	1.11
@@ -61,26 +61,27 @@
 <a href="http://biomoby.org">BioMOBY</a> Object Structure </h2>
 <div class="entrytext">
 
-It is our intention that MOBY Objects should be as lightweight as
-possible.  This not only reduces bandwith, speeds up service response
-time, and reduces server load, it also reduces conflict that arises
-from disagreement over the structure of more complex objects.  More importantly, however, it results in
- the creation of Services that have near-transparent semantics.  Because of the limited
- Service Ontology, the functionality of BioMoby services must be clearly
- described in a single word.  Generally speaking, if an Object contains
- "lots of information", the Service that generates it will be quite complex.
- Complex services cannot be described in the BioMoby system.  As such, BioMoby
- services attempt to be highly modular - complex data is derived by accessing
- a broader arrange of lightweight services and integrating this data client-side,
- in contrast to accessing a "one service provides all" Service whose output consists of many
- data-types.
+It is our intention that MOBY Objects should be as lightweight as 
+possible.  This not only reduces bandwith, speeds up service response 
+time, and reduces server load, it also reduces conflict that arises 
+from disagreement over the structure of more complex objects. 
+More importantly, however, it results in the creation of Services that 
+have near-transparent semantics. Because of the limited 
+Service Ontology, the functionality of BioMoby services must be clearly 
+described in a single word.  Generally speaking, if an Object contains 
+"lots of information", the Service that generates it will be quite complex. 
+Complex services cannot be described in the BioMoby system.  As such, BioMoby 
+services attempt to be highly modular - complex data is derived by accessing 
+a broader arrange of lightweight services and integrating this data client-side, 
+in contrast to accessing a "one service provides all" Service whose output 
+consists of many data-types.
 </p>
 
 MOBY Object structure is inferred by looking up the Object Class in
 the Class Ontology.  Each node in the ontology is a different Class
 Name, and each arc is a relationship of the type ISA (inheritance),
-HASA (container of exactly one of the given class), or HAS (container
-of one or more of the given class).  ISA relationships are guaranteed
+HASA (container of maximal one object of the given class), or HAS (container
+of zero or more of the given class). ISA relationships are guaranteed
 to be acyclic.
 </p>
 
@@ -89,7 +90,7 @@
 
 All MOBY Objects inherit from the root "Object" Class, and since
 complex objects can only be derived through inheritence from (ISA), or
-combination of (HASA) existing objects, every sub-object in a complex
+combination of (HASA/HAS) existing objects, every sub-object in a complex
 object is, itself, a valid MOBY Object which inherits directly or
 indirectly from the "Object" Class.
 </p>