Entity sets - containment and parent-child

[Mark Beall]

On Nov 16, 2009, at 2:54 PM, Tim Tautges wrote:

> A
>> couple of questions:
>> - createAssociation implies that there can only be a single  
>> relation between two interfaces. Offhand I can't think of a example  
>> of where there might be more than one, but it seems it might be  
>> possible.
>
> I think so too.  This is one of the reasons I think it's useful to  
> have distinct "relation" objects.  The fact that the interface  
> doesn't seem to support a variety of uses is more a factor of nobody  
> really using it besides me.
>
> In the longer run, I see there being other pairwise relations too,  
> e.g. a field with a tag.

However, in the case where there is more than one relation possible,  
there would also need to be a way to "describe" what relation you are  
asking for. At this point it would seem that if I'm asking for a mesh- 
model relation, then I'm, by definition, asking for classification.

Also, I think there is a need to define what would be in the  
classification relation. By "define" here, I either mean that it's  
documented what this particular relation will be or there is a way for  
the user to request that certain information be there.

For example, let's consider a model face and the mesh classified on  
it. I can see reasonable implementations that would only give the list  
of mesh faces classified on the model face, in our implementation I  
can also give you the mesh edges and vertices. If an application needs  
the vertices classified on a model face it's going to work with one  
implementation and not with the other (unless the developer is very  
careful to code for every possible case - and I think it's kind of a  
waste for every developer to have to do that).

>> - why does createAssociation take in whether the relation is an  
>> entity or a set rather than that being returned? It makes sense if  
>> the relation is empty, doesn't really make sense if the relation is  
>> something like our classification that already exists (or  
>> classification in general since there really should only be one way  
>> to describe that).
>
> In most cases you can support either, and which one you want depends  
> on the usage.  I think this would be far more useful though if there  
> were a function to change the type of relation dynamically.   
> Requesting an entity-set type be changed to an entity-both type, and  
> back again, for smoothing, is the easiest use case for this, but  
> adaptive refinement is another good example.

I don't think I understand why you would want to change the relation.  
If I have classification as an entity-set relation, why would I want  
it differently. I will say that I'm assuming that  
iRel_getEntEntAssociation always allows you to efficiently query the  
relation in either direction (this is implied due to the existence of  
the "switch_order" argument).

mark