<div dir="ltr">All,<div><br></div><div>I'm just coming off of leave, and catching up on this thread.</div><div>A couple quick thoughts:</div><div> </div><div>> PH: "I can follow all of  Std&Doc rules and all of the VO-DML std rules and produce PhotDM 1.2 with entirely different VODML-IDs - It is not sensible, but it is legal,"</div><div>A version 1.2 of the model with completely different VODML-IDs would not be considered backward compatible, so not qualify as a 1.2.</div><div>I suppose it would be true that a V2.0 of the model could have completely different VODML-IDs defined.</div><div><br></div><div>> MD:  "And that's where it is a MIVOT issue after all -- this entire thread wouldn't have happened if we decided to sunset the VODML-ids now.  It's still easy at this point, and it'll be nigh impossible once MIVOT uses them."</div><div>I agree with the statement in principle.. if there is a serious issue with using VODML-IDs to identify the role of an object that should be resolved before MIVOT uses it.</div><div>However, I don't really understand the issue here (need to spend some more time on it). </div><div><br></div><div>> PH: "Once it is agreed that the VODML-IDs are UTypes then they can be dropped entirely as they are mechanically created from the model structure"</div><div>VODML-IDs are not the same as UTypes, they do not change due to context as UTypes do.  A "coords:TimeFrame.timescale" does not change when used within a Cube, TimeSeries, Mango, etc. instance.</div><div><br></div><div>Do I have this correct?  The convention of generating VODML-IDs as "<ClassName>.<attribute name>" has created the perception that they are redundant with the actual attribute name when used to identify the role of the item in MIVOT annotation.</div><div><br></div><div>Mark</div><div><br></div><div><br></div></div>