[vodml] Attribute multiplicity

[Markus Demleitner]

Dear DMers,

On Wed, Dec 30, 2015 at 12:54:17PM -0500, CresitelloDittmar, Mark wrote:
> A couple quick comments.
> 
> 1) various [string 0..*] attributes
>     I agree that all of the examples I gave represent concepts
>     which **could** be expanded with other attributes.  In that
>     regard, modeling them as such would be more 'correct'.
>     However, we have NO use cases which require any more than the
>     simple string representation.  So the question becomes "is it
>     cost effective to do so?".

Let me put in a bit of experience from Registry modelling efforts
here, as I believe this is a classic of the old saying that there's
nothing more practical than a good theory.

In the (informal) models behind the Registry, there's a number of
person-like entities -- creator, publisher, contact, contributor.
When the models were written, it seemed wise to model each entity in
an ad-hoc manner, such that, for instance, only a contact can have a
telephone number, and only creators and contacts have logos.

This made total sense at the time -- after all, what would a client
do with a logo of a contributor?  But as soon as you start doing
something unforseen -- like perhaps a relational mapping -- all these
well-meaning shortcuts tend to make things complicated, and after a
while you end up introducing extra code ("business logic") that has
nothing to do with the world but is only needed because of the little
shortcuts you took in your model.

So, I'd pose the question: Is it cost effective *not* to do the
proper modelling?  My suspicion is: probably almost never.  Perhaps
your XML may look a bit more complicated when you actually model your
universe of discourse rather than some guess at what your model might
be used for in the future, but that's more than weighed up by it
being more regular and thus easier to handle with actual code.


>     And this is the point.  I/we understand that we are not doing
>     justice to the "Contributor" concept (for example), but the
>     simple string array attribute is easier to interpret and serves
>     the requirements.

Well, it *may* be easier to interpret for humans, but for programmers
and thus machines such shortcuts usually turn out to be more work.  


> 2) Polynomial
>     My initial reaction is "what you describe is an entirely
>     different goal".  The STC Transform model is not trying to
>     model the mathematical operations/functions.  It is

Why not?  It would seem to me that WCS, which has been reasonably
successful at what you're trying to do, is doing exactly that, no?

>     encapsulating the user-provided specifications required by
>     those operations.  The Axis, for example, is not part of the

I'm not sure I follow the difference -- are you saying the actual
expressions are expected to be opaque to the model?


  -- Markus