I think we're talking at cross purposes. The *only* differences between my position and Seegyoung's are that 1) I proposed adding something like "SetArr" for symmetry, and 2) I moved the suggested flag ("EntArr") to a different enumeration because doing so more closely reflects established terminology in relational databases. Unless you think #1 would be difficult/impossible to implement (which it may be, I don't know the internals of your software), we appear to be arguing about the name of a parameter.
I can't speak for Tim, Jason, or anyone else at ANL or UW, but I'm agreeing with Seegyoung's proposal in every respect except the naming scheme.
- Jim
On 10/28/10, Mark Shephard <shephard(a)scorec.rpi.edu> wrote:
> Jim,
>
> There is no disagreement that some of the suggestions are not optimal. However, when a very simple added function that would do exactly what was needed was suggested Tim indicated it, and as near as I and others can tell anything like it, was simply not acceptable to him.
>
> I believe that the early emails on the iRel problems by Mark Beall and papers that go back to the 90's have clearly defined the simple capability requested. To this point any of the suggestions from the MOAB team that come close to supporting the need you are calling an unacceptable hack. If you do not like any of them, then please work with Seegyoung on defining something that will work for all.
>
> Note that if we ever want to converge, the solution has to consider needs other than what one understands at this point in time to be a good implementation without hacks which is heavily based on the ITAPS interface implementations they work with. I can assure you that using sets as defined in iMesh do things we do very cleanly during mesh modifications would look very much like a hack. However, for other things, many of which MOAB focuses on, sets are a nice way to do it. What is common, that is in the ITAPS interfaces, needs to have some consideration of the needs of all implementations that are actually being used to do things.
>
> It would be nice to actually focus the iRel discussion on support of relations as they are used in simulations using unstructured meshes. That is let everyone state their requirements for relations and then define something that meets all of them. I though that irrespective of if specific options were "hacks" or not, Jason's email from earlier was in that direction. I also though that the suggestions made in Seegyoung 3:15am email were also in that direction (while trying to not change much of what was in place).
>
> Again, I request that you and Seegyoung work on something that you can both accept and then present it to the rest of us. This is the approach taken by Tim and I to define iGeom and that seamed to work. If successful at a minimum it should give us a starting point that can be build on that will work. In my opinion the seamingly simple nature of supporting relations, which is the stated goal of iRel, should be much easier that iGeom.
>
> Mark
>
> On 10/28/10 8:07 PM, James Porter wrote:
> >On Thu, 2010-10-28 at 18:58 -0400, seol(a)scorec.rpi.edu wrote:
> >>>On Thu, 2010-10-28 at 03:12 -0400, seol(a)scorec.rpi.edu wrote:
> >>>>4. adding "EntArr" to "Relation Type" and removing iRel_getEntSetIter& iRel_getEntArrSetIterArr
> >>>>
> >>>> CURRENT Relation Type: Ent, Set, Both (Ent&Set)
> >>>> NEW: Ent, Set, Both (Ent&Set), EntArr
> >>>
> >>>Assuming we end up agreeing that directly encoding one-to-many
> >>>relationships in iRel (instead of relying on iMesh/iGeom to give us this
> >>>though sets and/or iterators), I don't think this is a good way to go
> >>>about doing it as it's really just a hack to work around implementations
> >>>that don't support sets.
> >>
> >>vice versa. supporting set-only relation type is not a good way either as it requires a hack to work around
> >>implementation that don't use sets as a way of grouping of multiple data
> >
> >You're talking about hacks to an implementation. I mean hacks to the
> >interface; the EntArr proposal seems to be operating under the premise
> >that we shouldn't change any of the other parts of iRel to help you guys
> >out, so you have to "bolt on" a new feature. Really, the current way
> >isn't good for you guys, but EntArr doesn't help us in any way. We'd end
> >up with two parallel interfaces that the "other guys" would have no use
> >for except as a compatibility layer.
> >
> >The problem here is that iRel obviously needs to support a one-to-many
> >relation *somehow*, and currently, it tries to do this by piggybacking
> >on sets from iMesh/iGeom. That's what the "Set" relation type is.
> >Obviously this is bad for implementations that don't use sets, but I
> >think it's bad in general. It makes the implementation less clear, and
> >if we want to support one-to-many relations (without deferring
> >*completely* to iMesh/iGeom sets), we should commit to that instead of
> >doing it partway (EntArr doesn't help one-to-many-sets, for instance).
> >
> >Besides, there's no logical difference between "RelationType = {Ent,
> >Set, EntArr, SetArr}" and "RelationType = {Ent, Set}, CardinalityType =
> >{One, Many}"*, but the latter way pushes iRel closer to "traditional"
> >relational DBs, which can only be a good thing, if for no other reason
> >than that it's easier to write documentation for.
> >
> >* I'm ignoring Both for now, just for simplicity.
> >
> >>>Don't take the above suggestion as endorsement, though. As the
> >>>maintainer of (currently) the only iRel implementation, I should note
> >>>that doing this (either your way or mine) will significantly increase
> >>>the complexity and decrease the potential for interoperability** of iRel
> >>>unless the iMesh and iGeom specs are updated as well.
> >>
> >>It's not clear why not having EntArr relation type. Please describe the following.
> >> - how iRel, iMesh and iGeom should be updated further by having EntArr relation type.
> >
> >Again, I'm not saying that something equivalent to "EntArr" is bad, but
> >that calling it that is limiting to us (there's no "SetArr"). Pulling it
> >out into a "cardinality" flag does the same thing but reads better.
> >
> >However, either EntArr or my cardinality alternative would require us to
> >significantly change how our iRel implementation works. If we stick with
> >represent "many" as just a set, then we have to add a lot of extra logic
> >to handle creating a one-to-many relation that isn't already backed by a
> >set. The code for EntEntArr relations is already fairly brittle in
> >Lasso, and I'd rather it not get worse.
> >
> >The "clean" alternative is to store the "many" directly on a tag, but
> >that would mean we need variable-length tags in iMesh/iGeom or we have
> >to fall back to MOAB's native interface, which would make it more
> >difficult to use Lasso with any other implementation (or to port it
> >over).
> >
> >> - why EntArr and Set are not othorgonal so iRel shouldn't have EntArr relation type losing the generality (limiting
> >>its capability to support one-to-(set)many only).
> >
> >I'm not sure what exactly you mean by this, but if two things are
> >orthogonal, as you seem to be suggesting, I think it makes sense for
> >them to be represented as different parameters.
> >
> >> - why MOAB/Lasso cannot support EntArr relation type to account for FMDB-like implementation as we do support set
> >>relation type to account for MOAB-like implementation in all other interfaces.
> >
> >I haven't said that we can't do this, only that it makes things
> >significantly more complicated for us. As I already mentioned, my
> >alternative doesn't actually make things any simpler for us, it just
> >makes the interface clearer.
> >
> >- Jim
> >
