<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 4, 2016 at 5:05 AM, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear DMers,<br>
<span class=""><br>
On Wed, Dec 30, 2015 at 12:54:17PM -0500, CresitelloDittmar, Mark wrote:<br>
> A couple quick comments.<br>
><br>
> 1) various [string 0..*] attributes<br>
> I agree that all of the examples I gave represent concepts<br>
> which **could** be expanded with other attributes. In that<br>
> regard, modeling them as such would be more 'correct'.<br>
> However, we have NO use cases which require any more than the<br>
> simple string representation. So the question becomes "is it<br>
> cost effective to do so?".<br>
<br>
</span>Let me put in a bit of experience from Registry modelling efforts<br>
here, as I believe this is a classic of the old saying that there's<br>
nothing more practical than a good theory.<br>
<br>
In the (informal) models behind the Registry, there's a number of<br>
person-like entities -- creator, publisher, contact, contributor.<br>
When the models were written, it seemed wise to model each entity in<br>
an ad-hoc manner, such that, for instance, only a contact can have a<br>
telephone number, and only creators and contacts have logos.<br>
<br>
This made total sense at the time -- after all, what would a client<br>
do with a logo of a contributor? But as soon as you start doing<br>
something unforseen -- like perhaps a relational mapping -- all these<br>
well-meaning shortcuts tend to make things complicated, and after a<br>
while you end up introducing extra code ("business logic") that has<br>
nothing to do with the world but is only needed because of the little<br>
shortcuts you took in your model.<br></blockquote><div><br><br></div><div>I'm not sure I follow you here. I certainly am not suggesting that we flatten<br></div><div>required structure. I'm asking if we need to add unrequired structure.<br></div><div>The examples for this case are from the DatasetMetadata document, <br></div><div>the content of which is heavily rooted in the Resource Metadata document.<br></div><div><br></div><div>The DatasetMetadata model also has these person-like entities -- creator, publisher, contact..<br></div><div>creator and publisher are modeled as simple strings, contact is an object <br></div><div>since there is a requirement for more structure (name, email). It (contact)<br></div><div>does NOT contain other elements which are listed in the RM document,<br></div><div>(address, telephone) since we have no use-cases where those elements<br></div><div>are needed.<br><br></div><div>No one has commented that the simplification of these entities to a string <br>is a problem. These elements have a 0..1 multiplicity, so are valid vo-dml.<br></div><div>So, why then, should it be a problem for 'Collection' to be simplified to a<br></div><div>single string.. simply because there can be more than one?<br><br></div>For the record, I am OK with the resolution being that all of these person-like<br></div><div class="gmail_quote">entitites should be modeled more formally (whether the structure is required<br></div><div class="gmail_quote">or not), both the single and multiple relations. In which case, this group<br></div><div class="gmail_quote">of conflicts with vo-dml multiplicity would go away. However, without that sort <br></div><div class="gmail_quote">of comment/decision being posted to the DatasetMetadata document, they <br></div><div class="gmail_quote">exist.<br></div><div class="gmail_quote"><br><br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, I'd pose the question: Is it cost effective *not* to do the<br>
proper modelling? My suspicion is: probably almost never. Perhaps<br>
your XML may look a bit more complicated when you actually model your<br>
universe of discourse rather than some guess at what your model might<br>
be used for in the future, but that's more than weighed up by it<br>
being more regular and thus easier to handle with actual code.<br>
<span class=""><br>
<br>
> And this is the point. I/we understand that we are not doing<br>
> justice to the "Contributor" concept (for example), but the<br>
> simple string array attribute is easier to interpret and serves<br>
> the requirements.<br>
<br>
</span>Well, it *may* be easier to interpret for humans, but for programmers<br>
and thus machines such shortcuts usually turn out to be more work.<br>
<span class=""><br>
<br>
> 2) Polynomial<br>
> My initial reaction is "what you describe is an entirely<br>
> different goal". The STC Transform model is not trying to<br>
> model the mathematical operations/functions. It is<br>
<br>
</span>Why not? It would seem to me that WCS, which has been reasonably<br>
successful at what you're trying to do, is doing exactly that, no?<br>
<span class=""><br>
> encapsulating the user-provided specifications required by<br>
> those operations. The Axis, for example, is not part of the<br>
<br>
</span>I'm not sure I follow the difference -- are you saying the actual<br>
expressions are expected to be opaque to the model?<br>
<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote><div><br></div><div>Yes, and I think that is consistent with what WCS provides.. <br></div><div>The expression for generating a Tangent plane projection is opaque, <br></div><div>one merely knows that it is TAN, the projection point, and corresponding pixel,<br></div><div>(ie: encapsulation of the interface).<br><br></div><div>Mark<br><br></div></div></div></div>