[Bioperl-l] parent <-> subject etc

[Hilmar Lapp]

So this is now changed to (subject_term,predicate_term,object_term)  
both on main trunk and stable branch. Tests pass.

There is still the OntologyEngineI and inheriting from it the OntologyI  
API that has calls like

	get_child_terms(TermI)
	get_parent_terms(TermI)
	get_ancestor_terms(TermI)
	get_descendant_terms(TermI)

(all methods also accept an optional predicate to filter by). This  
nomenclature doesn't play well with the RelationshipI terminology now.  
Also,

	get_root_terms()
	get_leaf_terms()

are, IMHO, prone to prompt confusion in conjunction with the  
(subject,predicate,object) terminology. As an example, after adding  
terms A and B and the triple

	A binds B

would you expect to find A as a root term or as a leaf in the graph?  
(under the child-subject correspondence, B would be the root and A is  
then a leaf)

The terminology used in Graph.pm is successors(), predecessors(), and  
neighbors(). There is no equivalent for ancestors and descendants.

ChrisM in his proposal back in last year had methods in GraphVocabI like

	get_covered_terms(TermI)
	get_covered_by_terms(TermI)
	get_subclass_terms(TermI)
	get_superclass_terms(TermI)

(all with get_all_XXX variants). I find it still very confusing (no  
offense Chris) what these exactly mean, how it would translate to  
(subject,predicate,object), and what the difference is between covered  
terms and covered-by terms. Also, given the previous example

	A binds B

I quite frankly can't tell where A and where B would be returned to me.

I'd appreciate any input, comment, advice, consolation :)

Matt, Thomas, any insight or ideas you'd like to share?

	-hilmar

On Monday, March 24, 2003, at 12:55  PM, Chris Mungall wrote:

>
> i'm *strongly* in favour of subj/pred/obj, for the reasons outlined  
> below.
> parent/child will become incredibly confusing for any ontology that has
> more than partof and isa relationships. surely the onus is on you to
> justify divergence from both the entire ontology community & bioSQL?
>
> On Mon, 24 Mar 2003, Hilmar Lapp wrote:
>
>> I have to rush away, hence in short. Yes, you're pretty late. To be
>> more precise, this terminology in the ontology modules has been there
>> since October last year, and I've been asking people to check out the
>> interfaces since 3 weeks. (!)
>>
>> If there's a community vote to change it, I'm willing to change it.
>> It's Ewan who decides whether this goes into 1.2.1 or will be another
>> API change down the road.
>>
>> 	-hilmar
>>
>> On Monday, March 24, 2003, at 08:27  AM, Lincoln Stein wrote:
>>
>>> A little late for me to chime in here, I know, but I would avoid
>>> "child" and
>>> "parent" terms because they imply a directionality that is  
>>> appropriate
>>> for
>>> some, but not all, relationships.  Same for target and source.
>>>
>>> (subject,predicate,object) is nicely neutral and accepted in the
>>> ontology
>>> community.  For the uninitiated, (subject,relationship type,object)  
>>> is
>>> easier
>>> to understand.
>>>
>>> Lincoln
>>>
>>>
>>> On Wednesday 19 March 2003 04:04 pm, Chris Mungall wrote:
>>>> On Wed, 19 Mar 2003, Hilmar Lapp wrote:
>>>>> There are different names around for the triple (actually, a
>>>>> quadruple
>>>>> with the namespace) making up the relationship between two  
>>>>> vertices:
>>>>>
>>>>> 	(subject,predicate,object)
>>>>>
>>>>> or
>>>>>
>>>>> 	(child,relationship type,parent)
>>>>>
>>>>> or
>>>>>
>>>>> 	(target,relationship type,source)
>>>>>
>>>>> Some people have expressed in the past that some of these  
>>>>> depictions
>>>>> are inferior to others for some reason or another, which quite
>>>>> frankly
>>>>> I don't agree with (e.g., subject/predicate/object may make a lot  
>>>>> of
>>>>> sense for ontology terms, but not really for feature graphs). To me
>>>>
>>>> for containment graphs or is-a inheritance graphs, the semantics of
>>>> 'parent' vs 'child' is obvious, but this is not the case for other
>>>> kinds
>>>> of graph. using subject/object there is no potential for ambiguity.
>>>>
>>>>> it's mostly a matter of taste, consistency, and documentation to  
>>>>> make
>>>>> sure the directionality doesn't get confused (feature graphs,
>>>>> bioentry-bioentry relationships, and term-term relationships are  
>>>>> all
>>>>> directed).
>>>>>
>>>>> So, just to be sure I'm not confused already, if I define that the
>>>>> last
>>>>> (3rd) element in the aforementioned tuples has the smaller distance
>>>>> to
>>>>> the root along the 1st element's path to the root, then the order  
>>>>> of
>>>>> elements above depicts the equivalent designations, right?
>>>>
>>>> if you're asking if they are all equivalent, yes. ie child=subject
>>>>
>>>> i think it's wrong to thing in terms of graphs that are always  
>>>> rooted
>>>> -
>>>> what about cyclical graphs?
>>>>
>>>>> Once we all agree on this I'll document it in RelationshipI and the
>>>>> biosql schema.
>>>>>
>>>>> 	-hilmar
>>>>
>>>> _______________________________________________
>>>> Bioperl-l mailing list
>>>> Bioperl-l at bioperl.org
>>>> http://bioperl.org/mailman/listinfo/bioperl-l
>>>
>>> --
>>> ===================================================================== 
>>> ==
>>> =
>>> Lincoln D. Stein                           Cold Spring Harbor
>>> Laboratory
>>> lstein at cshl.org			                  Cold Spring Harbor, NY
>>> ===================================================================== 
>>> ==
>>> =
>>>
>>>
>>
>
>
-- 
-------------------------------------------------------------
Hilmar Lapp                            email: lapp at gnf.org
GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
-------------------------------------------------------------