search

whitten / colore

Automatically exported from code.google.com/p/colore, (probably official copy at https://github.com/gruninger/colore also check out https://github.com/tillmo/colore )
0 stars 0 forks source link

Module name consistency #1

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
There is currently no single consistent module naming convention within COLORE. 
 Some modules use the file name for the module name (e.g. see actocc.clif).  
Other modules use the filename less the extension (e.g. see psl-core).  Some 
use a module name that differs in case from the filename (e.g. see rt.clif).  
Some use the Camel Case naming convention (e.g. see 
orthocomplementedlattice.clif) while others use the hyphen convention (e.g. 
near-linear.clif). 

The CL standard recommends that URIs be used within CL dialects intended for 
use on the web.  Whilst CLIF is not specifically targeting the web, it stands 
to reason that importations within a CLIF file may reference named texts and 
modules that need to somehow be resolved.  URIs are an accepted mechanism for 
doing this.  Also, the intension to eventual deploy COLORE within an "online" 
repository that publishes its content through a collection of RESTfull web 
services.  Therefore, I recommend that the following actions be considered:

1) Obtain an Internet domain name for colore (colore.ca is currently available).

2) Adopt a COLORE file naming convention that uses all small letters with 
underscores separating words (e.g. psl_core.clif).

3) All modules are named according to best practices for designing URIs.  For 
example, http://oor.colore.ca/ontologies/psl_core.  All CLIF texts importing 
the psl_core ontology would refer to this URI which is universally locatable. 

Cameron.

Original issue reported on code.google.com by cross%ko...@gtempaccount.com on 26 Aug 2010 at 6:02

GoogleCodeExporter commented 9 years ago 
I totally agree. I would like to add that

4) All modules should include the relative path in the repository in their 
names. I did this for the theories in foundational\contact_algebras and 
generic\mereotopologies.

For example the path for the RCC would be:
[domain to be added]/ontologies/generic/mereotopologies/rcc
For the Boolean Contact Algebras it would be:
[domain to be 
added]/ontologies/foundational/contact_algebras/boolean_contact_algebras

For now we can use relative domains until we obtain and actively use the 
[domain to be added], e.g. oor.colore.ca.

Torsten

Original comment by torstenh...@gmail.com on 26 Nov 2010 at 4:14