Search Mailing List Archives
[protege-owl] New Plugin: The BioPortal Reference Widget - insert external references in the ontology
AHMadani at mdanderson.org
Mon Aug 10 12:09:35 PDT 2009
Are these the only annotations we can import the value from Bioportal to our local ontology for binding purposes through Bioportal widget?
[cid:image001.png at 01CA19C4.25A846B0]
From: protege-owl-bounces at lists.stanford.edu [mailto:protege-owl-bounces at lists.stanford.edu] On Behalf Of Tania Tudorache
Sent: Friday, July 31, 2009 10:32 PM
To: User support for the Protege-OWL editor
Cc: OBI Developers; Philippe Rocca Serra; Melanie Courtot
Subject: Re: [protege-owl] New Plugin: The BioPortal Reference Widget - insert external references in the ontology
Thank you for your suggestions. I like solution (b). The plugin was
developed for another use case, in which the ontology was not even OWL
or RDF, but Protege frames that does not support RDF, or URIs, etc.
The plugin is quite flexible and already does the "hard work" of
searching in BioPortal, querying the entity details, building the UI,
etc. The actual import happens in one small method that is
straightforward to change. If a project has other requirements, and a
Java developer with some experience and 1-2 hours of time, it is very
easy to adapt the plugin to other types of import.
I am happy to make the change, but I don't have time right now. I'll be
away the entire next week and when I get back things look very busy. We
are happy to integrate any contributions into the plugin and distribute
it in the Protege installation.
Alan Ruttenberg wrote:
> On Wed, Jul 29, 2009 at 4:09 PM, Tania Tudorache<tudorache at stanford.edu> wrote:
>> Hi Alan,
>> Thank you very much for the valuable feedback.
>> The goal of the plugin is to allow users to reference and navigate to terms
>> in BioPortal; and the plugin has been implemented with this goal in mind. It
>> was not intended at all as a generic referencing plugin, but specifically
>> to link ontologies in Protege to BioPortal.
> Thanks for clarifying, though I have to say there is still something
> that is hard to understand about this. After all, it wouldn't be an
> end goal to link ontologies to the bioportal (as much as the NCBO
> might like to hope for this this :). Presumably they want to link to
> the Bioportal for a reason, and it is that reason that I think
> deserves some thought.
>> Please see below my comments.
>> Alan Ruttenberg wrote:
>>> Hello Tanya,
>>> I think this is a great start, but I am concerned about the
>>> consequences of the RDF that it generates.
>>> First, it creates instance of type ExternalReference that represent
>>> other terms, but doesn't insert the term itself for use in the
>>> ontology being constructed. As a result it encourages the
>>> proliferation of URIs that mean the same thing, certainly not a good
>>> practice for Semantic Web purposes. In OWL, one uses *URI*s to do
>>> reference. This is what the tool should do too.
>> I agree that having "double" referencing URIs is not good. We will follow
>> your advice, and in the next version of the plugin, we should also include
>> the real URI of the referenced term as part of the external reference.
> The suggestion is that it isn't part of the external reference. The
> proposal is that it *is* the reference.
>> idea with the reference to BioPortal is to have a URL that the user can
>> click and go to BioPortal directly to that concept. And this is exactly what
>> the plugin does.
> If that were the sole goal, for example to be able to provide
> additional documentation, then a single property value for foaf:page,
> asserted on the term in question, would solve the problem.
>> It is more like linking to an "external" documentation of
>> the term, e.g., linking to a pdf. So, the plugin was not intended as
>> "mapping" plugin, in which references to the real URI would indeed be very
> If it is external documentation of the term, then the bioportal page
> linked to would be the that for the term itself. If not it is,
> implicitly at least, a kind of mapping, whether intended or not. I
> discourage this sort of thing in favor of more explicitly relating the
> targeted resource to the one that references, even with the OBO
> ontologies, where I have complained about the use of Dbxrefs. However
> the usage here is more problematic because in the OBO case an argument
> could be made that the link was ontology->database, and so mapping was
> out of the question, whereas in this case it is ontology->ontology.
> Wouldn't you think that terms so referenced, particularly if they were
> documentation for a term, would signify that they are intended to mean
> the same thing?
>> In any case, I see your point and I will include the full URI of
>> the referenced entity from BioPortal.
>>> Second, it suggests creating a new annotation property to relate the
>>> bioportal page to the term being created (url). However there are
>>> already existing properties that should at least serve as a better
>>> default than encouraging a user to create an new, non understood
>>> property - for example, foaf:topicOf. I would suggest collecting a set
>>> of commonly used such properties and offering these to the user with
>>> the purpose of aiming towards convergence of usage.
>> Maybe the documentation is not clear. You can use it with any property,
>> including foaf:topicOf. The documentation says that the plugin can be
>> attached to any annotation , object property, or RDF property.
> There are two properties. The first is the one that links the term in
> your ontology to the instance of external reference. The second is the
> one that links the external reference to the bioontology page. The
> latter is what I was referring to.
> <ontologyName rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
> >Ontology for Biomedical Investigations</ontologyName>
> <preferredTerm rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
> <ontologyId rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
> --> <url rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
> <conceptId rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
> But to be clear, what I would expect is that either:
> a) If the term for which an external reference is chosen is the term
> already in the ontology, an annotation is directly asserted on the
> term. Taking an example from OBI, if I am viewing
> http://purl.obolibrary.org/obo/OBI_0000066 in protege and I click
> add-external reference I would hope the following triple would be
> <http://purl.obolibrary.org/obo/OBI_0000066> foaf:page
> I realize that you allow there to be any property in place of where I
> have written foaf:page. My specific suggestion was that you offer
> foaf:page and the 3 or 4 most commonly used properties to the user
> before encouraging them to figure it out for themselves, which most
> likely will lead to a proliferation of properties that mean the same
> b) Don't add external reference, add the external term. Supposing that
> you need "investigation" in your ontology. Protege offers to MIREOT
> (see the reference below) the term into your ontology directly by
> including the triples:
> <http://purl.obolibrary.org/obo/OBI_0000066> rdf:type owl:Class
> <http://purl.obolibrary.org/obo/OBI_0000066> owl:subClassOf <parent
> class selected>
> <http://purl.obolibrary.org/obo/OBI_0000066> importedFrom
> <http://purl.obolibrary.org/obo/OBI_0000066> rdfs:seeAlso
> <http://purl.obolibrary.org/obo/OBI_0000066> protege:termAddedBy
> In neither case is there an instance of ExternalReference created.
>>> Third it does not include, even with the ExternalReference, the URI
>>> that the ontology developer considers authoritative for the term, nor
>>> does it mention the location of the ontology. OWL has ways of doing
>>> this, and they involve using URIs. Both "term"s and "ontologies" are
>>> not english labels - They are primarily identified by the URI but this
>>> is not pulled in by the import.
>> True. The external reference only contains the information returned from the
>> BioPortal search rest service. It is a good idea to include the full URI of
>> the referenced ontology and of the term.
>>> Finally, the annotations that are pulled by the plugin will need to be
>>> updated in time, as the underlying terminologies evolve - is there a
>>> plan to have some service that indicates that a term that is being
>>> used in this way has been deprecated? Or that the term has changed in
>>> some way?
>> BioPortal does support to a certain degree the evolution of an ontology. It
>> provides a virtual id for an ontology that will always point to the latest
>> version of an ontology. So, even if you make the reference to a term, when
>> the latest ontology version was 2.4, and next month there is a 2.5 version
>> of the ontology, the virtual ontology id will always link to the latest
>> ontology version (in this case 2.5). So, the external reference could point
>> to the latest version of the ontology and term.
>> The current implementation of the plugin uses the version id of the ontology
>> (not the virtual id), so it will always point to the version to which it was
>> linked originally. We could change this, and even make it configurable, to
>> give the user the option of always linking to the latest ontology version.
>> Of course, this does not solve all ontology evolution problems, but I think
>> it goes a long way. If you have other suggestions on how to solve the
>> ontology evolution problems, we are happy to hear them.
> I was specifically concerned with the additional information pulled down, e.g.
> <preferredTerm rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
> The preferred term may change later.
> Members of the OBI team have written about what we do in our process,
> which is to have a specification of the external term, and a
> re-runnable set of sparql queries which pull in additional information
> that we want. The additional information is periodically updated by
> discarding the old information and re-running the script.
> A paper documenting this and other practices we have found useful, as
> presented at OWLED 2008, is
> A paper on importing, specifically, was presented at ICBO:
> The slides presented at ICBO are
> The specific file we use for OBI to define the imported term is
> The templates for the SPARQL CONSTRUCT queries we use to pull in
> information are at
> And the code that processes them:
> Additionally, there is now a web-based second implementation of the
> process developed by Oliver He's group at
> The OBI group would love it if we could do what we needed within
> protege. Given the interest in MIREOT at ICBO, I suspect a lot of
> other groups would as well.
>>> On Tue, Jul 28, 2009 at 9:36 PM, Tania Tudorache<tudorache at stanford.edu>
>>>> The BioPortal Reference Plugin allows a user *to insert references to
>>>> classes, etc. from external ontologies and terminologies* stored in
>>>> BioPortal <http://bioportal.bioontology.org/> into his or her own
>>>> without the need to import the external ontology. The plugin allows the
>>>> *easy navigation* from the domain ontology in Protege to the external
>>>> ontology by simply clicking on the generated *hyperlink of a reference*.
>>>> hyperlink will take the user directly into BioPortal to the referenced
>>>> The user may also search BioPortal for alternative terms.
>>>> The plugin is configurable and works with Protege 3.4.1 OWL, RDF, Frames,
>>>> client-server and all backends of Protege.
>>>> The plugin is a slot widget that can be attached to any object or
>>>> property in OWL, or any slot with value type instance, class or any in
>>>> The user guide and download link are available on the Protege wiki:
>>>> protege-owl mailing list
>>>> protege-owl at lists.stanford.edu
>>>> Instructions for unsubscribing:
>>> protege-owl mailing list
>>> protege-owl at lists.stanford.edu
>>> Instructions for unsubscribing:
>> protege-owl mailing list
>> protege-owl at lists.stanford.edu
>> Instructions for unsubscribing:
> protege-owl mailing list
> protege-owl at lists.stanford.edu
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03
protege-owl mailing list
protege-owl at lists.stanford.edu
Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1555 bytes
More information about the protege-owl