Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Ontology"

(New page: == Software component ontology == Software components shall be described through an OWL ontology. Core properties and classes shall be - Product development and release related metadata ...)
 
(Software component ontology)
 
Line 4: Line 4:
  
 
- Product development and release related metadata (i.e. same properties as those captured by Maven POM, OSGi manifest headers and/or DOAP; those schemas could be augmented).
 
- Product development and release related metadata (i.e. same properties as those captured by Maven POM, OSGi manifest headers and/or DOAP; those schemas could be augmented).
 +
 
- Reputation.
 
- Reputation.
 +
 
- License information.
 
- License information.
 +
 
- License style (capturing different licenses’ similarities could be useful).
 
- License style (capturing different licenses’ similarities could be useful).
 +
 
- Activity level.
 
- Activity level.
 +
 
- Functionalities.
 
- Functionalities.
 +
 
- Implemented API or frameworks (i.e. EJB 3.0 specification, or the JDBC API).
 
- Implemented API or frameworks (i.e. EJB 3.0 specification, or the JDBC API).
 +
 
- Hierarchically organized common features (i.e.: logging, persistence, parsing; Maven Repository’s tags cloud could be taxonomically organized, acting as a good starting point to formally describe software libraries in terms of functional features and areas).
 
- Hierarchically organized common features (i.e.: logging, persistence, parsing; Maven Repository’s tags cloud could be taxonomically organized, acting as a good starting point to formally describe software libraries in terms of functional features and areas).

Latest revision as of 06:19, 28 April 2007

Software component ontology

Software components shall be described through an OWL ontology. Core properties and classes shall be

- Product development and release related metadata (i.e. same properties as those captured by Maven POM, OSGi manifest headers and/or DOAP; those schemas could be augmented).

- Reputation.

- License information.

- License style (capturing different licenses’ similarities could be useful).

- Activity level.

- Functionalities.

- Implemented API or frameworks (i.e. EJB 3.0 specification, or the JDBC API).

- Hierarchically organized common features (i.e.: logging, persistence, parsing; Maven Repository’s tags cloud could be taxonomically organized, acting as a good starting point to formally describe software libraries in terms of functional features and areas).

Back to the top