Difference between revisions of "Ontology Notes"

From NCBO Wiki
Jump to navigation Jump to search
Line 296: Line 296:
 
</success>
 
</success>
 
</pre>
 
</pre>
 +
 +
= 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 [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html W3C's documentation on HTTP methods].
 +
 +
== Types of notes in BioPortal ==
 +
The following are the types of notes in BioPortal. Please, email us at [mailto:support@bioontology.org support@bioontology.org] if you have suggestions for other note types (or specific parameters for the notes).
 +
 +
* Basic comments (as they are in BioPortal currently)
 +
* Proposals
 +
** New term proposal
 +
** New relationship proposal
 +
** New attribute value proposal
 +
 +
=== Creating a 'Comment' note ===
 +
 +
* '''Signature (HTTP POST)''': ./notes/virtual/{ontology virtual id}?type=Comment&appliesto={appliestoid}&appliestotype={appliestotype}&subject={subject}&content={content}&author={author}&email={email_address}
 +
* '''Alt Signature (HTTP POST)''': ./notes/{ontology version id}?type=Comment&appliesto={appliestoid}&appliestotype={appliestotype}&subject={subject}&content={content}&author={author}&email={email_address}
 +
* '''Description''': creates a new note of the type 'Comment'
 +
* '''Arguments''':
 +
** type=Comment - the type of note to create.
 +
** 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|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.
 +
 +
=== Creating a 'New Term Proposal' note ===
 +
 +
* '''Signature (HTTP POST)''': ./notes/virtual/{ontology virtual id}?type=ProposalForNewEntity&appliesto={appliestoid}&appliestotype=Ontology&subject={subject}&content={content}&author={author}&relationshiptype={realtionshiptype}&relationshiptarget={relationshiptarget}&oldrelationshiptarget={oldrelationshiptarger}&email={email_address}
 +
* '''Alt Signature (HTTP POST)''': ./notes/{ontology version id}?type=ProposalForNewEntity&appliesto={appliestoid}&appliestotype={appliestotype}&subject={subject}&content={content}&author={author}&relationshiptype={realtionshiptype}&relationshiptarget={relationshiptarget}&oldrelationshiptarget={oldrelationshiptarger}&email={email_address}
 +
* '''Description''': creates a new note of the type 'New Term Proposal'
 +
* '''Arguments''':
 +
** type=ProposalForNewEntity - the type of note to create.
 +
** 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 - 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.
 +
** newtermdefinition={definition} - Definition for the new term.
 +
** newtermid={termid} - Proposed or generated id for the new term.
 +
** newtermparent={termparent} - ID for the parent of the new term.
 +
** newtermpreferredname={preferredname} - Preferred name for the new term.
 +
** newtermsynonyms={synonym1,synonym2,synonym3} - Synonyms for the new term. Can be a single entry or comma-separated list.
 +
 +
=== Creating a 'Change Relationship/Hierarchy' note ===
 +
 +
* '''Signature (HTTP POST)''': ./notes/virtual/{ontology virtual id}?type=ProposalForChangeHierarchy&appliesto={appliestoid}&appliestotype={appliestotype}&subject={subject}&content={content}&author={author}&newtermdefinition={definition}&newtermid={termid}&newtermparent={parent}&newtermpreferredname={preferredname}&newtermsynonyms={listofsynonyms}&email={email_address}
 +
* '''Alt Signature (HTTP POST)''': ./notes/{ontology version id}?type=ProposalForChangeHierarchy&appliesto={appliestoid}&appliestotype={appliestotype}&subject={subject}&content={content}&author={author}&newtermdefinition={definition}&newtermid={termid}&newtermparent={parent}&newtermpreferredname={preferredname}&newtermsynonyms={listofsynonyms}&email={email_address}
 +
* '''Description''': creates a new note of the type 'Comment'
 +
* '''Arguments''':
 +
** type=ProposalForChangeHierarchy - the type of note to create.
 +
** 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 - 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).
 +
 +
=== Creating a 'Change Property Value' note ===
 +
 +
* '''Signature (HTTP POST)''': ./notes/virtual/{ontology virtual id}?type=ProposalForPropertyValueChange&appliesto={appliestoid}&appliestotype={appliestotype}&subject={subject}&content={content}&author={author}&newpropertyvalue={newvalue}&oldpropertyvalue={oldvalue}&propertyid={propertyid}&email={email_address}
 +
* '''Alt Signature (HTTP POST)''': ./notes/{ontology version id}?type=ProposalForPropertyValueChange&appliesto={appliestoid}&appliestotype={appliestotype}&subject={subject}&content={content}&author={author}&newpropertyvalue={newvalue}&oldpropertyvalue={oldvalue}&propertyid={propertyid}&email={email_address}
 +
* '''Description''': creates a new note of the type 'Change Property Value'
 +
* '''Arguments''':
 +
** type=ProposalForPropertyValueChange - the type of note to create.
 +
** 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 - 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.

Revision as of 18:27, 26 April 2010

Ontology 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.

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).

  • Basic comments (as they are in BioPortal currently)
  • Proposals
    • New term proposal
      • Generated ID
      • PrefName
      • Synonym
      • Definition
      • Superclass
      • Comment
    • New relationship proposal
      • Relationship type: is-a, part-of
      • Relationship target
    • New attribute value proposal
      • Attribute: documentation, definition, etc.
      • New value
      • Flag: replaces the current value (which one, in case of multiple values) or in addition to the current value(s)
      • Special kind of new attribute value proposal: Assigning UMLS semantic type
        • Semantic type
        • Semantic typeID
  • (for later) Structured annotations with user-defined structure
  • (for later) Usage-guideline notes

Services to access and generate notes

(Note: We are currently working on these services. They are not available yet! If you have specific requirements that the list of services below does not satisfy, please contact us at support@bioontology.org)

Get notes for an ontology by version id

  • Signature: ./notes/{ontology version id}?email={email_address}
  • Description: returns all notes for a specific version of the ontology
  • Optional arguments:
    • conceptid={conceptid} - returns notes associated with the given term.
    • instanceid={isntanceid} - returns notes associated with the given instance (individual).
    • noteid={noteid} - returns notes associated with the given note id.
    • threaded=[true|false] - returns notes in a threaded format where responses are nested in their parent notes. Default is false.
    • Planned (not yet implemented):
      • notetype={notetype} - returns only the notes of the specific type.
      • includearchived=[true|false] - include archived notes. Default is false.

Get notes for an ontology by virtual id

  • Signature: ./virtual/notes/{ontology virtual id}?email={email_address}
  • Description: returns all notes for the virtual ontology, i.e., all notes associated with any version of this ontology
  • Optional arguments:
    • conceptid={conceptid} - returns notes associated with the given term.
    • instanceid={isntanceid} - returns notes associated with the given instance (individual).
    • noteid={noteid} - returns notes associated with the given note id.
    • threaded=[true|false] - returns notes in a threaded format where responses are nested in their parent notes. Default is false.
    • Planned (not yet implemented):
      • notetype={notetype} - returns only the notes of the specific type.
      • includearchived=[true|false] - include archived notes. Default is false.

Sample of the XML returned for a note

A single 'Comment' note

<?xml version="1.0" encoding="UTF-8"?>
<success>
  <accessedResource>/bioportal/virtual/notes/1104</accessedResource>
  <accessDate>2010-04-26 13:02:57.418 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>
      </noteBean>
    </list>
  </data>
</success>

A single 'New Term Proposal' note

<?xml version="1.0" encoding="UTF-8"?>
<success>
  <accessedResource>/bioportal/virtual/notes/1104/</accessedResource>
  <accessDate>2010-04-26 18:13:24.407 PDT</accessDate>
  <data>
    <list>
      <noteBean>
        <id>Note_f8bb4dc0-10b3-48b9-ab69-79aed042c0ff</id>
        <ontologyId>1104</ontologyId>
        <type>ProposalForNewEntity</type>
        <author>1234</author>
        <created>1272319359680</created>
        <updated>1272319377224</updated>
        <subject>Test Proposal Reply</subject>
        <body>Testing new term submission</body>
        <appliesToList>
          <appliesTo>
            <fullId>1104</fullId>
            <type>Ontology</type>
          </appliesTo>
        </appliesToList>
        <values>
          <ProposalForNewEntity>
            <reasonForChange>Bad data</reasonForChange>
            <contactInfo>palexander@stanford.edu</contactInfo>
            <id>TERM_1100</id>
            <preferredName>New Term</preferredName>
            <definition>Test new definition</definition>
            <synonyms>
              <string>bestterm</string>
              <string>amazingterm</string>
              <string>greatterm</string>
            </synonyms>
            <parent>
              <string>http://www.owl-ontologies.com/2009/9/24/Ontology1253802770.owl#Summary</string>
            </parent>
          </ProposalForNewEntity>
        </values>
      </noteBean>
    </list>
  </data>
</success>

A single 'Change Relationship/Hierarchy Proposal' note

<?xml version="1.0" encoding="UTF-8"?>
<success>
  <accessedResource>/bioportal/virtual/notes/1104</accessedResource>
  <accessDate>2010-04-26 18:21:52.474 PDT</accessDate>
  <data>
    <noteBean>
      <id>Note_b4e749c8-5ca7-414f-a123-acd16ba656fe</id>
      <ontologyId>1104</ontologyId>
      <type>ProposalForChangeHierarchy</type>
      <author>1234</author>
      <created>1272331290991</created>
      <updated>1272331295114</updated>
      <subject>Change Relationship</subject>
      <body>Testing change hierarchy</body>
      <appliesToList>
        <appliesTo>
          <fullId>http://bioontology.org/ontologies/BiomedicalResourceOntology.owl#Clinical_Data</fullId>
          <type>Class</type>
        </appliesTo>
      </appliesToList>
      <values>
        <ProposalForChangeHierarchy>
          <reasonForChange>Incorrect data</reasonForChange>
          <contactInfo>palexander@stanford.edu/contactInfo>
          <relationshipTarget>
            <string>root</string>
          </relationshipTarget>
          <oldRelationshipTarget>
            <string>isa</string>
          </oldRelationshipTarget>
        </ProposalForChangeHierarchy>
      </values>
    </noteBean>
  </data>
</success>

A single 'Property Value Change Proposal note

<?xml version="1.0" encoding="UTF-8"?>
<success>
  <accessedResource>/bioportal/virtual/notes/1104</accessedResource>
  <accessDate>2010-04-26 18:25:30.465 PDT</accessDate>
  <data>
    <noteBean>
      <id>Note_8cfde654-2c2c-42e3-8187-0f6c05c6deff</id>
      <ontologyId>1104</ontologyId>
      <type>ProposalForPropertyValueChange</type>
      <author>1234</author>
      <created>1272331520036</created>
      <updated>1272331522822</updated>
      <subject>Tet Property Value Change</subject>
      <body>Testing a proposal to change a property value</body>
      <appliesToList>
        <appliesTo>
          <fullId>http://bioontology.org/ontologies/BiomedicalResourceOntology.owl#Clinical_Data</fullId>
          <type>Class</type>
        </appliesTo>
      </appliesToList>
      <values>
        <ProposalForPropertyValueChange>
          <reasonForChange>The value was entered incorrectly initially</reasonForChange>
          <contactInfo>palexander@stanford.edu</contactInfo>
          <newValue>200</newValue>
          <oldValue>100</oldValue>
          <propertyId>Cell_Count</propertyId>
        </ProposalForPropertyValueChange>
      </values>
    </noteBean>
  </data>
</success>

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>
                <fullId>Note_0a78922c-3d1e-4689-8af8-48d10d4cdaa8</fullId>
                <type>Ontology</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>
                    <fullId>Note_02e4b8cd-f582-411c-8561-035a0f7d1dd9</fullId>
                    <type>Ontology</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>
                    <fullId>Note_02e4b8cd-f582-411c-8561-035a0f7d1dd9</fullId>
                    <type>Ontology</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).

  • Basic comments (as they are in BioPortal currently)
  • Proposals
    • New term proposal
    • New relationship proposal
    • New attribute value proposal

Creating a 'Comment' note

  • Signature (HTTP POST): ./notes/virtual/{ontology virtual id}?type=Comment&appliesto={appliestoid}&appliestotype={appliestotype}&subject={subject}&content={content}&author={author}&email={email_address}
  • Alt Signature (HTTP POST): ./notes/{ontology version id}?type=Comment&appliesto={appliestoid}&appliestotype={appliestotype}&subject={subject}&content={content}&author={author}&email={email_address}
  • Description: creates a new note of the type 'Comment'
  • Arguments:
    • type=Comment - the type of note to create.
    • 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|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.

Creating a 'New Term Proposal' note

  • Signature (HTTP POST): ./notes/virtual/{ontology virtual id}?type=ProposalForNewEntity&appliesto={appliestoid}&appliestotype=Ontology&subject={subject}&content={content}&author={author}&relationshiptype={realtionshiptype}&relationshiptarget={relationshiptarget}&oldrelationshiptarget={oldrelationshiptarger}&email={email_address}
  • Alt Signature (HTTP POST): ./notes/{ontology version id}?type=ProposalForNewEntity&appliesto={appliestoid}&appliestotype={appliestotype}&subject={subject}&content={content}&author={author}&relationshiptype={realtionshiptype}&relationshiptarget={relationshiptarget}&oldrelationshiptarget={oldrelationshiptarger}&email={email_address}
  • Description: creates a new note of the type 'New Term Proposal'
  • Arguments:
    • type=ProposalForNewEntity - the type of note to create.
    • 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 - 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.
    • newtermdefinition={definition} - Definition for the new term.
    • newtermid={termid} - Proposed or generated id for the new term.
    • newtermparent={termparent} - ID for the parent of the new term.
    • newtermpreferredname={preferredname} - Preferred name for the new term.
    • newtermsynonyms={synonym1,synonym2,synonym3} - Synonyms for the new term. Can be a single entry or comma-separated list.

Creating a 'Change Relationship/Hierarchy' note

  • Signature (HTTP POST): ./notes/virtual/{ontology virtual id}?type=ProposalForChangeHierarchy&appliesto={appliestoid}&appliestotype={appliestotype}&subject={subject}&content={content}&author={author}&newtermdefinition={definition}&newtermid={termid}&newtermparent={parent}&newtermpreferredname={preferredname}&newtermsynonyms={listofsynonyms}&email={email_address}
  • Alt Signature (HTTP POST): ./notes/{ontology version id}?type=ProposalForChangeHierarchy&appliesto={appliestoid}&appliestotype={appliestotype}&subject={subject}&content={content}&author={author}&newtermdefinition={definition}&newtermid={termid}&newtermparent={parent}&newtermpreferredname={preferredname}&newtermsynonyms={listofsynonyms}&email={email_address}
  • Description: creates a new note of the type 'Comment'
  • Arguments:
    • type=ProposalForChangeHierarchy - the type of note to create.
    • 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 - 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).

Creating a 'Change Property Value' note

  • Signature (HTTP POST): ./notes/virtual/{ontology virtual id}?type=ProposalForPropertyValueChange&appliesto={appliestoid}&appliestotype={appliestotype}&subject={subject}&content={content}&author={author}&newpropertyvalue={newvalue}&oldpropertyvalue={oldvalue}&propertyid={propertyid}&email={email_address}
  • Alt Signature (HTTP POST): ./notes/{ontology version id}?type=ProposalForPropertyValueChange&appliesto={appliestoid}&appliestotype={appliestotype}&subject={subject}&content={content}&author={author}&newpropertyvalue={newvalue}&oldpropertyvalue={oldvalue}&propertyid={propertyid}&email={email_address}
  • Description: creates a new note of the type 'Change Property Value'
  • Arguments:
    • type=ProposalForPropertyValueChange - the type of note to create.
    • 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 - 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.
Retrieved from "https://www.bioontology.org//mediawiki/index.php?title=Ontology_Notes&oldid=9885"