<div dir="ltr"><div>Paul,</div><div><br></div><div>I believe much of this conversation fits in work we had crystallized in a number of documents over the past 10 years, starting with requirements we collected from the IVOA community regarding data models and their serializations.</div><div><br></div><div>The old draft of the Mapping VODML to VOTABLE spec linked below lists a number of requirements and use cases for the serializations. See in particular sections 2.3.4 and 2.4. Some of the design decisions we are discussing come from those very explicit and detailed requirements. My experience tells me that there may be different ways of fulfilling those requirements, however what often risks getting lost in these conversations is the need to strike the balance among a number of competing requirements from the perspective of different potential client and server implementations. I can argue for a simplification that makes sense, but in doing so I might be blocking significant use cases that would require additional complexity. I don't think any single person can strike that balance, which is why in the past we strived to document as much of the rationale for a specific design as possible, as well as attempting a very formal approach to the mapping of VODML to other meta-models like VOTABLE, but also OOP and Relational Schemata, with an eye on the Object-Relational mistmatch. Much of that thoroughness was ditched in subsequent approaches that focused on alleged simplicity.</div><div><br></div><div>My point is that the answer to some of your comments may depend on the kind of client we are implementing and how we want to use the data. For example, a client might be interested in all the instances that contain std:Type.attribute1 and std:Type.attribute2, irrespective of the instance type they belong to, duck-typing style, confident that the semantics of those attributes are exactly what they are supposed to be according to the std: data model. How does a mapping specification enable that while also allowing a client who couldn't care less about specific types to provide a dictionary-like, weakly typed, human readable representation of the same instance? Note that in neither case there's any just-in-time parsing of the model xml documents. In the former case the data model is assumed and maybe even hard coded in the client's implementation, in the other it is completely ignored. Other use cases might include a pre-parsing of the model xml, or even a just-in-time parsing.</div><div><br></div><div>If one wants to leave the door open for additional usages of the serialization, using the full vodm-id provides a future proof solution for a little price in terms of complexity.</div><div><br></div><div><a href="https://volute.g-vo.org/svn/trunk/projects/dm/vo-dml-mapping/doc/VO-DML_mapping_WD.pdf">https://volute.g-vo.org/svn/trunk/projects/dm/vo-dml-mapping/doc/VO-DML_mapping_WD.pdf</a><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 8, 2023 at 6:20 AM Paul Harrison <<a href="mailto:paul.harrison@manchester.ac.uk">paul.harrison@manchester.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><div><br><blockquote type="cite"><div>On 7 Mar 2023, at 22:52, Laurino, Omar <<a href="mailto:olaurino@cfa.harvard.edu" target="_blank">olaurino@cfa.harvard.edu</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_quote"><div>I really hope I didn't miss some connections in this long thread, but...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The real point is that the VODML-ID "coords:TimeFrame.timescale” could be "coords:a.b" according to the VO-DML standard - there is no connection between the vodml-id and the name of the model element as defined in the standard - I want to make the connection, and once the connection is made, the VODML-ID is redundant as it can be generated from the model structure.<br></blockquote><div><br></div><div>A change could be made to the VODML spec to make the vodml-id generation a requirement rather than a preference, by promoting Appendix C to normative state. And while I remember believing that both approaches (full vodml-id or just name) would work, as long as the mapping provides enough markup to make the references unambiguous, I did have a preference for the full vodml-id for two reasons: 1. because explicit is better than implicit and 2. because it is more future-proof.</div></div></div></div></blockquote><div><br></div>I had not noticed Appendix C - so yes I would support making that normative, and moving it out of the appendix - that does at least part of what I am arguing for. In fact I am more concerned by this happening rather than my slightly more controversial desire to remove VODML-IDs….they would just be repeated information then.</div><div><br></div><div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div>If I understand Paul's point correctly, I'd like to point out that the reason for having the entire vodml-id was to make sure that a model's element could always be identified unambiguously in any context, in particular when extending models. VODML allows data providers to extend a type (section 4.6.1). When they do, parsers need a way to identify fields in an unambiguous way, which includes mapping them to the model document where they are defined.</div><div><br></div><div>In that sense, the vodml-id becomes redundant not only if one makes the connection with the name, but also if a mapping scheme defines a way to represent extensions that provides that unambiguous mechanism. If an instance is of type <custom:MyType> (which extends standard:Type), one would have attributes identified by <custom:MyType.myAttribute> and <standard:Type.attribute> within that instance, which the parser could map to the respective definitions without having to rely on any heuristics or complex logic.</div><div><br></div><div>If one has a <custom:MyType> instance with attributes <myAttribute> and <attribute> the parser wouldn't really know where to look them up unless the connection between <custom:MyType> and <standard:Type> is made explicit in the serialization markup. And even in that case, since the parser doesn't know whether myAttribute is defined in custom: or in standard: it'll have to try both.</div></div></div></blockquote><br>Agreed that you would have to traverse the hierarchy, but I am not convinced that much value is obtained from having a data model representation unless you are prepared to do that. Even if you have some code that does a simple switch-case-statement-like string match on VODML-IDs to do “stuff” for a standard:Type, how are you going to arrange things for the custom:MyType? It quickly gets messy if you just keep adding to the monster “global” switch statement for all the possibilities. It is actually not impossible that you might want to do something different for <attribute> when it appears in custom:MyType compared with when it appears in standard:Type.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>People have argued in the past that inheritance requires parsers to have complex type algebra, which may be true depending on the use case and of the mapping strategy. However, extensibility was one of the main requirements for VODML. A mapping strategy can minimize that effort by identifying an instance as both custom:MyType and standard:Type. And since we recommend vodml-ids to be generated algorithmically, a parser could decide to ignore model definitions completely, and parse the vodml-ids to display the attribute names, which would be human-readable. Other parsers would be interested in the unambiguous identification of attributes to provide richer context-dependent features to client software.</div><div><br></div></div></div></blockquote></div><div>I think that identifying attributes from an inheritance hierarchy would only become “difficult” (i.e. requiring more than the name) if VO-DML allowed multiple inheritance. However it does not, so I do not think that the extra naming is necessary if there is a rule that attribute names have to be unique within the parents of the hierarchy - the only case where overrides can occur is explicitly dealt with by subsetting.</div><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div><br></div><div>A reference to a full vodml-id is always going to unambiguously identify a single element, like a URI. I can go from custom:MyType.myAttribute to myAttribute and from standard:Type.attribute to attribute, but I can't go from myAttribute to custom:MyType.myAttribute without some effort parsing definition documents.</div><div><br></div></div></div></div></blockquote>So here I concede that more parsing of the definition documents would be needed without the VODML-ID - however given that the definition documents are XML it is necessary to do more than simple string matching to have any sort of robustness, so the documents would need to read as DOM at a minimum and then traversing the hierarchy looking for a particular element from a VODML-REF is not so much more effort. If appendix C were mandatory, then my objection to VODML-IDs is on the DRY principle. To create an in-memory index for referencing the various elements, the key could be formed either by just reading the VODML-ID or by constructing it from the hierarchy path.</div><div><br></div><div>Paul.</div><div><br></div><div><br></div><br></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr" style="margin-left:0pt" align="left"><table style="border:none;border-collapse:collapse"><colgroup><col width="445"><col width="275"></colgroup><tbody><tr style="height:90pt"><td style="border-width:1pt;border-style:solid;border-color:rgb(255,255,255);vertical-align:top;padding:5pt;overflow:hidden"><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9.5pt;font-family:Arial;color:rgb(34,34,34);background-color:transparent;font-weight:700;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Omar Laurino (he/him)<br></span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9.5pt;font-family:Arial;color:rgb(34,34,34);background-color:transparent;font-weight:700;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Smithsonian Astrophysical Observatory<br></span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9.5pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:700;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Center for Astrophysics | Harvard & Smithsonian</span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9.5pt;font-family:Arial;color:rgb(34,34,34);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Office: </span><span style="font-size:9.5pt;font-family:Arial;color:rgb(34,34,34);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><span style="color:rgb(153,153,153)"><a value="+16174957227" style="color:rgb(17,85,204)">(617) 495-7227</a></span></span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9.5pt;font-family:Arial;color:rgb(34,34,34);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">100 Acorn Park Dr. R-377  | MS 81 | Cambridge, MA 02140</span></p></td></tr><tr style="height:27pt"><td style="border-width:1pt;border-style:solid;border-color:rgb(255,255,255);vertical-align:top;padding:5pt;overflow:hidden"><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><span style="border:none;display:inline-block;overflow:hidden;width:149px;height:65px"><img src="https://lh6.googleusercontent.com/LhgpVKQcoGZf0WT8tH85tnqc5udPHbDWpffp9Qd6X8R_6ymoDWOlxyiZZ8ZHwax3bRo6hRTKaHn9-6UomsZB1qIItvtZdv2D1Tr6tLuMdkFnPItmmZJZOltYQpSMsUa1h9AeVe9b" style="margin-left: 0px; margin-top: 0px;" width="149" height="65"></span></span></p><br><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><a href="http://cfa.harvard.edu/" style="text-decoration:none" target="_blank"><span style="font-size:9.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:400;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">cfa.harvard.edu</span></a><span style="font-size:9.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"> | </span><a href="https://www.facebook.com/CenterForAstrophysicsHarvardSmithsonian/" style="text-decoration:none" target="_blank"><span style="font-size:9.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:400;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">Facebook</span></a><span style="font-size:9.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"> | </span><a href="https://twitter.com/CenterForAstro" style="text-decoration:none" target="_blank"><span style="font-size:9.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:400;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">Twitter</span></a><span style="font-size:9.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"> | </span><a href="https://www.youtube.com/channel/UC-UUo6Y7fP0N41Qw7KcKtcQ" style="text-decoration:none" target="_blank"><span style="font-size:9.5pt;font-family:Arial;color:rgb(34,34,34);background-color:rgb(255,255,255);font-weight:400;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">YouTube</span></a><span style="font-size:9.5pt;font-family:Arial;color:rgb(34,34,34);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"> | </span><a href="https://harvard.us14.list-manage.com/subscribe/post?u=13f357b8637e4a05e4a5d2845&id=c6100e9a6c" style="text-decoration:none" target="_blank"><span style="font-size:9.5pt;font-family:Arial;color:rgb(34,34,34);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">Newsletter</span></a></p></td></tr></tbody></table></div></div><br></div></div>