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.
Difference between revisions of "Software provisioning ontology"
(New page: The core concepts of the ontologies are Library and Component, both subclasses of a generic SWObject. It is useful to capture a group of different versions for the same component, identifi...) |
(→swpo.owl - Software Provisioning Ontology) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | The | + | == swpo.owl == |
| + | |||
| + | The swpo.owl ontology imports a set of legacy ontologies axiomatizating the domain of software components, available @ [http://cos.ontoware.org cos.ontoware.org]. | ||
| + | |||
| + | Core concepts of the ontologies are Library and Component, both subclasses of a generic SWObject. It is useful to capture a group of different versions for the same component, identified by the same instance of SWObjectID. | ||
[[Image:SWObject1.jpg]] | [[Image:SWObject1.jpg]] | ||
Latest revision as of 12:39, 28 June 2007
swpo.owl
The swpo.owl ontology imports a set of legacy ontologies axiomatizating the domain of software components, available @ cos.ontoware.org.
Core concepts of the ontologies are Library and Component, both subclasses of a generic SWObject. It is useful to capture a group of different versions for the same component, identified by the same instance of SWObjectID.
A component/library will have a set of TaskClass instances, identifying "what" the piece of software is going to do (logging, persistence, nlp, parsing, etc). This leads to infer a "weak" functional equivalence between components.
It could also comply to some specification (more or less formally defined), for instance restricting the input format, or the output format, or implementing a particular framework specification, the latter yielding a much more strict definition of functional equivalence.
It could be useful to enable search features driven by non-functional grouping criteria (i.e.: find all jakarta projects), so the notion of belonging to a NonFunctionalClass has been captured in the model as well.
The notion of License-style is captured in the model, at the moment as a simple one-to-many relationship. It could be nice to have in the future a more granular description of a license, to allow much smarter search criteria.
Only Maven and OSGi legacy repositories fall into GSoC's scope, but adding interaction capabilities with other legacy systems will be quite straightforward.
