Changes between Version 62 and Version 63 of ImplementationBootcamp

2010/02/12 11:14:31 (13 years ago)



  • ImplementationBootcamp

    v62 v63  
    3636Protege 3 and Protege 4 are "philosophically" different, and represent a split in the global ontology community that runs roughly along the lines of the "OBO-fans" and the "OWL-DL-fans" (that's over-simplifying the situation, but I think it is by-and-large correct).  The two development communities had different target-audiences in mind when developing the software, and those audiences are reflected in the decisions made.  Protege 4 uses the Manchester OWL API "under the hood", and is somewhat more capable of manipulating OWL than Protege 3 is.  On the other hand, if you are planning to use Protege to generate RDF data ("individuals") manually, then Protege 3 might be more useful for you. 
     38=== What are some other semantic web initiatives I should know about? === 
     40Aside from initiatives that were explicitly mentioned at the hackathon, here are some other ones not to ignore: 
     41 * A number of biomedical ontologies are collected by the [ NCBO BioPortal].  
     42 * For evolutionary biologists and phyloinformaticists there is [ CDAO],  
     43 * for taxonomists and biodiversity informaticists there is the [ TDWG ontology] and [ DarwinCore].  
     44If you are ontologizing your own problem domain, make an effort to align your terms with these efforts. The idea is that we're building one big graph that connects everything! 
     46=== How do I align ontologies? === 
     48At the [ VoCamp/TDWG satellite meeting in Montpellier (2009)], a [ working group devoted to this topic] developed the following recommendations: 
     50For ontology integration, our work has led us to conclude that: 
     51 * instance data should be fully ontologized. For example, our phenoscape use case could not be completed because phenoscape uses XML literals to express trait post-composition. These traits were consequently inaccessible for the purpose of data integration. 
     52 * ontologies should be designed as reusable modules rather than monolithic artifacts. Aligning [ CDAO] with [ DarwinCore] was relatively easy because DarwinCore doesn't have a lot of structure (which is a good thing from the perspective of re-use). (although DarwinCore still needs to be ontologized). 
     53 * data integration is most easily achieved by developing small adaptor ontologies rather than merging of large (and potentially well-established and "stable") artifacts. Merging large ontologies has a greater potential to have irreconcilable incongruities. Adapting smaller ontologies requires immediate reconciliation, but insulates the practitioner from irrelevant inconsistencies. Implementations are likely to be more efficient and scalable. Nevertheless, if two domains have significant overlap, it is probably better to merge them, reconcile the inconsistencies and thereby decrease the overall noise subsequent use of the domain.  
     54 * URIs (URLs) for terms should be carefully constructed, predictable and stabilized, perhaps using PURLs. For example, several queries failed to produce expected results due to omission of `www` prefixes or `#` suffixes in URLs. 
     55 * several tools (Homonto developed by [ BGee], [ LOOM]) and a lot of research ([ Ontology Matching]) has already gone into the problem of ontology alignment. However, expert knowledge for manual alignment is often still necessary. 
    3857=== In my generated RDF, what namespace URI do I use to prefix my terms? ===