Note: All NCBO REST Web services will be required to contain the parameter "apikey=YourApiKey" starting June 2011. The parameter will be added to all Web service calls for the April 27, 2011 release but will not be required until June 2011. To obtain an API key, login to BioPortal and go to "Account" where your API key will be displayed. The addition of the API key replaces the use of the email parameter.

Note for Application Developers: Application developers will also need to include the apikey parameter on all NCBO Web service calls. This allows us to track usage of our system at the level of an application. To obtain an API key, login to BioPortal and go to "Account" where your API key will be displayed. The addition of the API key replaces the use of the email parameter.

A nested thread of 'Comment' notes

<?xml version="1.0" encoding="UTF-8"?>
<success>
<accessedResource>/bioportal/virtual/notes/1104</accessedResource>
<accessDate>2010-04-26 13:21:28.104 PDT</accessDate>
<data>
<list>
<noteBean>
<id>Note_0a78922c-3d1e-4689-8af8-48d10d4cdaa8</id>
<ontologyId>1104</ontologyId>
<type>Comment</type>
<author>38143</author>
<created>1272070868364</created>
<updated>1272070868250</updated>
<subject>Including clinical trial data as clinical data</subject>
<body>I note that clinical data is specifically defined not to include clinical trial data. So is anyone already thinking about where at a high level subtrees might be added to deal with clinical trial data and clinical trial management systems? Or is it premature to do that? This is for the CTSAs.</body>
<createdInOntologyVersion>2</createdInOntologyVersion>
<appliesToList>
<appliesTo>
<fullId>http://bioontology.org/ontologies/BiomedicalResourceOntology.owl#Clinical_Data</fullId>
<type>Class</type>
</appliesTo>
</appliesToList>
<associated>
<noteBean>
<id>Note_02e4b8cd-f582-411c-8561-035a0f7d1dd9</id>
<ontologyId>1104</ontologyId>
<type>Comment</type>
<author>38144</author>
<created>1272070984380</created>
<updated>1272070984243</updated>
<subject>RE:Including clinical trial data as clinical data</subject>
<body>Not sure I follow the argument here.&nbsp; Clinical trial data is covered under PHI so no distinction there.&nbsp; Data generated in the course of delivering routine standard of care may be needed in the course of a clinical trial.&nbsp; Does this make clinical trial data an overlapping superset of clinical data?</body>
<createdInOntologyVersion>2</createdInOntologyVersion>
<appliesToList>
<appliesTo>
<noteId>Note_0a78922c-3d1e-4689-8af8-48d10d4cdaa8</noteId>
<type>Note</type>
</appliesTo>
</appliesToList>
<associated>
<noteBean>
<id>Note_6bdc5fae-bd95-492c-ab47-0aaae7a2193a</id>
<ontologyId>1104</ontologyId>
<type>Comment</type>
<author>38143</author>
<created>1272070985097</created>
<updated>1272070985195</updated>
<subject>RE:RE:Including clinical trial data as clinical data</subject>
<body>I was only reacting to the definition of BRO:Clinical_Data in the current version: "Any type of data obtained in the course of caring for humans outside of measurements obtained in clinical trials". I think I'm agreeing with you that clinical trial data should be overlapping clinical data (whether its a superset I'm not sure). So I'm not clear why the definition that is in the current version is there. Somehow this might be related to the fact that BRO:Data_Object is subclassed partly by function (eg clinical data) and partly by data type (eg image). I would think images could also be a type of clinical data.</body>
<createdInOntologyVersion>2</createdInOntologyVersion>
<appliesToList>
<appliesTo>
<noteId>Note_02e4b8cd-f582-411c-8561-035a0f7d1dd9</noteId>
<type>Note</type>
</appliesTo>
</appliesToList>
</noteBean>
<noteBean>
<id>Note_1b490c3a-dd19-458a-9446-5184e42d03ab</id>
<ontologyId>1104</ontologyId>
<type>Comment</type>
<author>38145</author>
<created>1272070986051</created>
<updated>1272070986093</updated>
<subject>RE: Including clinical trial data as clinical data</subject>
<body>Hi David and all,<br><br>Clinical Trial Data should probably be dealt with separately from Clinical Data<br>collected in the course of administering clinical care.&nbsp; The use of Clinical<br>Trial data will be governed by the Consent that the patient signs as part of the<br>IRB Protocol that is set up to allow its collection, while the use Clinical Care<br>Data will be governed by the HIPAA notification that the patient receives, as<br>well as any IRB Protocols set up for the research involved.<br></body>
<createdInOntologyVersion>2</createdInOntologyVersion>
<appliesToList>
<appliesTo>
<noteId>Note_02e4b8cd-f582-411c-8561-035a0f7d1dd9</noteId>
<type>Note</type>
</appliesTo>
</appliesToList>
</noteBean>
</associated>
</noteBean>
</associated>
</noteBean>
</list>
</data>
</success>

Creating Notes in BioPortal

BioPortal uses ontology notes to describe a variety of user-specified comments and metadata on ontology, including new-term proposals, proposals for changes, comments and questions about classes, and so on.

BioPortal and REST Principles

BioPortal utilizes REST principles to create, read, update, and delete resources. The following service documentation uses the HTTP POST method to create notes in the BioPortal system. For more information, please see W3C's documentation on HTTP methods.

Types of notes in BioPortal

The following are the types of notes in BioPortal. Please, email us at support@bioontology.org if you have suggestions for other note types (or specific parameters for the notes).

appliesto={appliestoid} - The id of the thing to associate the note with. This can be a class (term), individual, property, or another note. For classes, individuals, and properties, the specified id must exist in the target ontology. URIs must be URL-encoded.

appliestotype={Ontology|Class|Individual|Property|Note} - The type of the thing that the note is associated with.

subject={subject} - The subject for the comment.

content={content} - The content of the comment.

author={authorid} - The author's BioPortal user id.

status={status} - Status for this notes. The Changes and Annotation Ontology provides a default set of statuses for proposals (Submitted, Rejected, Under Discussion, Under Review, Approved, Rejected, Implemented, Published) but the service also accepts arbitrary strings.

* appliesto={appliestoid} - The id of the thing to associate the note with. This can be a class (term), individual, property, or another note. For classes, individuals, and properties, the specified id must exist in the target ontology. URIs must be URL-encoded.

* appliestotype={Ontology|Class} - The type of the thing that the note is associated with.

* author={authorid} - The author's BioPortal user id.

* reasonforchange={reason for change} - An explanation for why the proposal is being made.

* termpreferredname={preferredname} - Preferred name for the new term.

* termdefinition={definition} - Definition for the new term.

* termparent={termparent} - ID for the parent of the new term. Must be a valid IRI or 'root' to include the term at the root of the ontology.

subject={subject} - The subject for the comment.

content={content} - The content of the comment.

contactinfo={contact information} - Contact information for the entity making the request.

termsynonyms={synonym1,synonym2,synonym3} - Synonyms for the new term. Can be a single entry or comma-separated list.

status={status} - Status for this notes. The Changes and Annotation Ontology provides a default set of statuses for proposals (Submitted, Rejected, Under Discussion, Under Review, Approved, Rejected, Implemented, Published) but the service also accepts arbitrary strings.

Removed Arugments (no longer used):

newtermid={termid} - Proposed or generated id for the new term.

This has been removed to allow for automatic generation of temporary URI ids for use with terms. This will allow you to refer to a term immediately after creating a new term proposal.

appliesto={appliestoid} - The id of the thing to associate the note with. This can be a class (term), individual, property, or another note. For classes, individuals, and properties, the specified id must exist in the target ontology. URIs must be URL-encoded.

appliestotype=Class - The type of the thing that the note is associated with.

subject={subject} - The subject for the comment.

content={content} - The content of the comment.

author={authorid} - The author's BioPortal user id.

reasonforchange={reason for change} - An explanation for why the proposal is being made.

contactinfo={contact information} - Contact information for the entity making the request.

relationshiptype={relationshiptype} - The type of relationship that should be created (is_a, part_of, has_part, etc)

relationshiptarget={relationshiptarget} - The term to create the relationship with.

oldrelationshiptarget={oldrelationshiptarget} - The term that the relationship is being changed from (if different than relationshiptarget).

status={status} - Status for this notes. The Changes and Annotation Ontology provides a default set of statuses for proposals (Submitted, Rejected, Under Discussion, Under Review, Approved, Rejected, Implemented, Published) but the service also accepts arbitrary strings.

appliesto={appliestoid} - The id of the thing to associate the note with. This can be a class (term), individual, property, or another note. For classes, individuals, and properties, the specified id must exist in the target ontology. URIs must be URL-encoded.

appliestotype=Property - The type of the thing that the note is associated with.

subject={subject} - The subject for the comment.

content={content} - The content of the comment.

author={authorid} - The author's BioPortal user id.

reasonforchange={reason for change} - An explanation for why the proposal is being made.

contactinfo={contact information} - Contact information for the entity making the request.

newpropertyvalue={newpropertyvalue} - The new value for the property.

oldpropertyvalue={oldpropertyvalue} - The old value for the property.

propertyid={propertyid}= The ID of the property to change.

status={status} - Status for this notes. The Changes and Annotation Ontology provides a default set of statuses for proposals (Submitted, Rejected, Under Discussion, Under Review, Approved, Rejected, Implemented, Published) but the service also accepts arbitrary strings.

archivethread=true - Archives all of the notes that are listed as associated to the given note id plus all of their children.

unarchive=true - Unarchives the note with the given note id.

unarchivethread=true - Unarchives all of the notes that are listed as associated to the given note id plus all of their children.

type=Comment|ProposalForCreateEntity|ProposalForChangeHierarchy|ProposalForPropertyValueChange - the type of note.

appliesto={appliestoid} - The id of the thing to associate the note with. This can be a class (term), individual, property, or another note. For classes, individuals, and properties, the specified id must exist in the target ontology. URIs must be URL-encoded.

appliestotype=Property - The type of the thing that the note is associated with.

subject={subject} - The subject for the note.

content={content} - The content of the note.

author={authorid} - The author's BioPortal user id.

status={status} - Status for this notes. The Changes and Annotation Ontology provides a default set of statuses for proposals (Submitted, Rejected, Under Discussion, Under Review, Approved, Rejected, Implemented, Published) but the service also accepts arbitrary strings.