<div dir="ltr">Hi Paul<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 20, 2017 at 11:38 AM, Paul Harrison <span dir="ltr">&lt;<a href="mailto:paul.harrison@manchester.ac.uk" target="_blank">paul.harrison@manchester.ac.uk</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I was just looking at the subsetting feature of VO-DML with a view to implementing properly within VODSL and have noticed an inconsistency between the VO-DML document and the schema. From the document I can see that the intention is that SubsettedRole is a kind of Constraint - however, the schema also has a ‘subsets&#39; attribute (as an ElementRef) on Role - should this now be deleted?<br>
<br>
I think that I understand what the subsetting feature of the language is (though I might not have fully grasped the full scope intended)  - in very rough terms - to be able to specify that one of the “contained&quot; elements within a sub-type has a specific sub-type of the equivalent element within the parent-type. In this case I can see that it has most (exclusive?) use within Roles and so it is perhaps odd that the SubsettedRole is a kind of Constraint... as a Constraint can be set on any Type, and I am not sure that I can see that there is any place for the subsetting concept to be associated with Types that cannot contain Roles, so perhaps the vestigial “subsets” element on a Role is a better meta model….<br>
<br>
I know that the VO-DML spec is deep into RFC and I apologise for not bringing this up earlier, but the subsetting feature and the extent to which it can be used needs to be nailed down, as it is powerful and will probably have a rather strong influence on how detailed models are (I see that STC wants to make extensive use of it)<br>
<br>
<br></blockquote><div>Nice question.</div><div>&#39;subsets&#39; on Roole should be removed if it is there. SubsettedRole is the replacement for that concept.</div><div>The original implementation, having &#39;subsets&#39; on Role, would require us to redefine the inherited Role on the subtype.<br></div><div>Question then would be how to refer to the role in a serialization, i.e. would it get its own vodml-id, or a new one?</div><div>The latter would be confusing for people who are looking for instances of the role</div><div><br></div><div><div>Nice question.</div><div>&#39;subsets&#39; on Role should be removed if it is there. SubsettedRole is the replacement for that concept.</div><div><br></div><div>The original implementation, having &#39;subsets&#39; on Role, would require us to redefine the inherited Role on the subtype.<br></div><div>Apart from then also being forced to add name, datatype, description etc, we need to decide whether it would it get its own vodml-id, or a new one. The latter would be confusing for people who are looking for instances of the role as defined on the super type, using the vodml-id defined there.</div><div></div></div><div>So to avoid those issues, and also because we really think of &#39;subsetting&#39; as a constraint we defined SubsettedRole as a subclass of Constraint. It is a constraint because it constrains the instances of the inherited Role (most often a Composition).</div><div>It is a constraint defined on Type, because it is only for certain Types that the constraint exists.</div><div><br></div><div>Hope this is clear?</div><div><br></div><div>Cheers</div><div><br></div><div>Gerard</div><div><br></div><div><br></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">
Regards,<br>
        Paul.<br>
<br>
<br>
<br>
<br>
<br><br>
</blockquote></div></div></div>