<html><body class="ApplePlainTextBody" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br>* Lars Heuer<br><blockquote type="cite"><br></blockquote><blockquote type="cite">Subject Identifier / Subject Locator constraints<br></blockquote><blockquote type="cite">================================================<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">But if I state<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> person<br></blockquote><blockquote type="cite"> &nbsp;&nbsp;has-subject-identifier(1, 1, "http://psi\.mycompany\.com/person/.*")<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I'd expect to say, that every person must have one subject identifier<br></blockquote><blockquote type="cite">which starts with the the address "http://psi.mycompany.com/person/".<br></blockquote><br>We discussed this in Prague, and came to the conclusion that<br><br> &nbsp;- in the current draft, the regexp is not used for matching, but<br> &nbsp;- in the next draft, it will be used for matching.<br><br>That is, from now on, the cardinality part of the constraint applies to the subject identifiers which match the regexp.<br><br>The rationale for this is that this approach allows much more detailed control over subject identifiers than if the rule was that the constraint makes all subject identifiers conform to both the cardinalities and the regexp.<br><br><blockquote type="cite">The following topic would satisfy my constraint:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> john isa person;<br></blockquote><blockquote type="cite"> &nbsp;&nbsp;&lt;http://psi.mycompany.com/person/John>.<br></blockquote><br>Yes. Under both interpretations.<br><br><blockquote type="cite">The following topic wouldn't satisfy my constraint since it has two<br></blockquote><blockquote type="cite">subject identifiers which start with the given address:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> paul isa person;<br></blockquote><blockquote type="cite"> &nbsp;&nbsp;&nbsp;&nbsp;&lt;http://psi.mycompany.com/person/Paul>;<br></blockquote><blockquote type="cite"> &nbsp;&nbsp;&nbsp;&nbsp;&lt;http://psi.mycompany.com/person/Paul_McCartney>.<br></blockquote><br>Correct. Again under both interpretations.<br><br><blockquote type="cite">If I have an instance of person like the following:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> ringo isa person;<br></blockquote><blockquote type="cite"> &nbsp;&nbsp;&lt;http://psi.mycompany.com/person/Ringo>;<br></blockquote><blockquote type="cite"> &nbsp;&nbsp;&lt;http://psi.previous-company.com/p/Ringo>.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I'd expect that the TMCL constraint is satisfied.<br></blockquote><br>Under the current spec it would not be. After we changed it, it would be satisfied.<br><br><blockquote type="cite">If someone wants to limit the total number of subject identifiers and each of the subject identifiers must satisfy a regular expression, she can do it with the following expression:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> person<br></blockquote><blockquote type="cite"> &nbsp;&nbsp;has-subject-identifier(1, 1, "http://psi\.mycompany\.com/person/.*");<br></blockquote><blockquote type="cite"> &nbsp;&nbsp;has-subject-identifier(1, 1, ".*").<br></blockquote><br>Yes, this is the same conclusion we came to in the meeting. :-)<br><br><blockquote type="cite">This definition says: person has exactly one subject identifier which starts with the address "http://psi.mycompany.com/person/" and that it has exactly one subject identifier which is matched by '.*'.<br></blockquote><br>Yep.<br><br><blockquote type="cite">Name / Occcurence constraints<br></blockquote><blockquote type="cite">=============================<br></blockquote><blockquote type="cite">I have a similar problem with the name / occurrence constraints: If I<br></blockquote><blockquote type="cite">understand the TMQL expression correctly, card-min / card-max define<br></blockquote><blockquote type="cite">the total number of occurrences / names with that specified type.<br></blockquote><br>We changed this so that regexps no longer apply to a (topic type, name|occurrence type) combination, but to the name|occurrence type alone. This is because we see this type of constraint as being closely related to datatype constraints.<br><br>So this problem no longer exists.<br><br>--Lars M.<br>http://www.garshol.priv.no/blog/<br>http://www.garshol.priv.no/tmphoto/<br><br><br><br></body></html>