You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the example file in this repository, we use obo:RO_0002558 "has evidence" to connect a phyloreference to its expected or resolved node. For example:
So we could use the reverse relation (obo:RO_0002472 "is evidence for") to connect a node with their phyloreference. However, using a Nexus property of RO:0002472 or obo:RO_0002472 might be unclear in this context, and we would still need to distinguish between the expected resolution node and the actual resolution node.
I think our options are:
Go with RO:0002472 for the actual resolved node, and denote the expected node in the label (e.g. expected_Crocodylidae)
Come up with additional properties for these nodes (such as phyloref:expected etc. listed above). We would define them as annotation properties, with ranges of IRIs for phyloref:expected/phyloref:actual and strings for phyloref:expectedLabel/phyloref:actualLabel.
We could use a URL as the property name (e.g. [&http://ontology.phyloref.org/expectedPhyloref="http://example.org/phyloref/Crocodylidae"]) and have that URL resolve to a website that explains what it means for humans, and tells people how to represent this in RDF.
The text was updated successfully, but these errors were encountered:
We need the properties to be fully understandable without the prefix, since that might not be visible in RDF apps. So something like e.g. phyloref:expectedPhyloref.
I agree there's something to be said for having a non-opaque property for exporting NEXUS tree annotations. I'm not sure these need or should be annotation properties. More importantly, we can make them (or at least expectedPhyloref) a subproperty of the RO property.
For the "actual" pair of properties, this may deserve a little more thought. I don't think we really mean to say "this [node] is the actual evidence for this [phyloreference]", but more like "this phyloreference resolves to this node", or conversely, "this node is to where this phyloreference resolves". So if we can agree that "resolves to X" and "matches X" are sufficiently close semantically, we could use that?
In Klados PR phyloref/klados#313, we implement the following four Nexus properties:
phyloref:expected="[URI]"
: The phyloreference expected to resolve at this node (e.g.http://example.org/phyloref/Crocodylidae
).phyloref:expectedLabel="[label]"
: The label of the phyloreference expected to resolve at this node (e.g.Crocodylidae
).phyloref:actual="[URI]"
: The phyloreference that actually resolved at this node (e.g.http://example.org/phyloref/Crocodylidae
).phyloref:actualLabel="[label]"
: The label of the phyloreference that actually resolved at this node (e.g.Crocodylidae
).For example, a node could be annotated as:
In the example file in this repository, we use obo:RO_0002558 "has evidence" to connect a phyloreference to its expected or resolved node. For example:
phyloref-ontology/gators.ofn
Lines 189 to 200 in 2fc7cfc
So we could use the reverse relation (obo:RO_0002472 "is evidence for") to connect a node with their phyloreference. However, using a Nexus property of
RO:0002472
orobo:RO_0002472
might be unclear in this context, and we would still need to distinguish between the expected resolution node and the actual resolution node.I think our options are:
RO:0002472
for the actual resolved node, and denote the expected node in the label (e.g.expected_Crocodylidae
)phyloref:expected
etc. listed above). We would define them as annotation properties, with ranges of IRIs forphyloref:expected
/phyloref:actual
and strings forphyloref:expectedLabel
/phyloref:actualLabel
.We could use a URL as the property name (e.g.[&http://ontology.phyloref.org/expectedPhyloref="http://example.org/phyloref/Crocodylidae"]
) and have that URL resolve to a website that explains what it means for humans, and tells people how to represent this in RDF.The text was updated successfully, but these errors were encountered: