[vodml] Attribute multiplicity

[CresitelloDittmar, Mark]

On Mon, Jan 4, 2016 at 5:05 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> 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.
>


I'm not sure I follow you here.  I certainly am not suggesting that we
flatten
required structure.  I'm asking if we need to add unrequired structure.
The examples for this case are from the DatasetMetadata document,
the content of which is heavily rooted in the Resource Metadata document.

The DatasetMetadata model also has these person-like entities -- creator,
publisher, contact..
creator and publisher are modeled as simple strings, contact is an object
since there is a requirement for more structure (name, email). It (contact)
does NOT contain other elements which are listed in the RM document,
(address, telephone) since we have no use-cases where those elements
are needed.

No one has commented that the simplification of these entities to a string
is a problem.  These elements have a 0..1 multiplicity, so are valid vo-dml.
So, why then, should it be a problem for 'Collection' to be simplified to a
single string.. simply because there can be more than one?

For the record, I am OK with the resolution being that all of these
person-like
entitites should be modeled more formally (whether the structure is required
or not), both the single and multiple relations.  In which case, this group
of conflicts with vo-dml multiplicity would go away.  However, without that
sort
of comment/decision being posted to the DatasetMetadata document, they
exist.




> 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?
>
>
>
Yes, and I think that is consistent with what WCS provides..
The expression for generating a Tangent plane projection is opaque,
one merely knows that it is TAN, the projection point, and corresponding
pixel,
(ie: encapsulation of the interface).

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20160104/c1b824e2/attachment.html>