Menu
▾
▴
Re: [Psidev-ms-dev] MANIFESTO TIME! (was RE: more is_a vs. part_of errors?)
|
From: Matthew C. <mat...@va...> - 2007-10-08 21:00:25
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Brian Pratt wrote:
<blockquote cite="mid:01e201c809e9$221ec150$0e03000a@BRIANTECRA"
type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta name="Generator" content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";
color:black;}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal;
font-family:Arial;
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal;
font-family:Arial;
color:navy;}
span.m1
{color:blue;}
span.t1
{color:#990000;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="Section1">
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: navy;">Hi Matt,<o:p></o:p></span></font></p>
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: navy;"><o:p> </o:p></span></font></p>
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: navy;">Sorry, I had
meant to explicitly point out
how the XSD orientation addresses your synonym concerns, although in
the end I
think I misunderstood them. Each element has associated with it
precisely
one correct accession attribute value, and you can use that to
determine
whether or the element is actually the thing you suspect it is since
all true
synonyms point back to the same accession number. The element names
remain stable, as one would hope. I don’t understand, though, why
you’re interested in making it easy to *<b><span
style="font-weight: bold;">introduce</span></b>*
synonyms - I was assuming that the purpose of this standardization
effort was
to *<b><span style="font-weight: bold;">do away</span></b>* with
synonyms so as
to reduce ambiguity.</span></font></p>
</div>
</blockquote>
I agree that doing away with synonyms is pretty much the whole purpose
of a controlled vocabulary, both for values and for categories, but
others have apparently supported it (I think Lennart was the last one
to remind me of supporting synonyms which was the reason to give
controlled values accession numbers). If we had a CV format capable of
representing the controlled values, then that would be a simpler way to
maintain the synonyms than with the schema. This is because the CV is
organized by accession numbers, which are unique, whereas the schema is
organized by element names, which are usually unique but not always.<br>
<br>
<blockquote cite="mid:01e201c809e9$221ec150$0e03000a@BRIANTECRA"
type="cite">
<div class="Section1">
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: navy;"><o:p></o:p></span></font></p>
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: navy;"><o:p> </o:p></span></font></p>
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: navy;">I assume
semantic validation is a goal, or
we wouldn’t have the business with reflectron state going on. In
any case, a spec that doesn’t lead to semantic validation is a poor
sort
of spec.<o:p></o:p></span></font></p>
</div>
</blockquote>
Agreed.<br>
<br>
<blockquote cite="mid:01e201c809e9$221ec150$0e03000a@BRIANTECRA"
type="cite">
<div class="Section1">
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: navy;"><o:p> </o:p></span></font></p>
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: navy;">IS_A and
PART_OF already have well defined
meanings (see <a moz-do-not-send="true"
href="http://obofoundry.org/ro/">http://obofoundry.org/ro/</a>),
so we really can’t redefine them for our own purposes. The
mechanism for enumerating a value range just isn’t there, so the
authors
have tried to hack it with the inheritance techniques available, which
leads to
all the gyrations over how to add a new instrument type. This is just
a
sign that we’re trying to drive a screw with a hammer, or whatever
metaphor you prefer for a “not even wrong” scenario.</span></font></p>
</div>
</blockquote>
It seems that OBO is currently incapable of providing a way for us to
control the values for our categories and that it's not really intended
for that. So we either must extend it with support for that
relationship (as well as specifying types and ranges for uncontrolled
value categories), or forget it entirely and stick with the schema.
Personally I prefer the accession numbers for the categories and for
the values, so I'd rather extend the OBO format with the features we
need unless such an extension would be prohibitively difficult to
implement.<br>
<br>
<blockquote cite="mid:01e201c809e9$221ec150$0e03000a@BRIANTECRA"
type="cite">
<div class="Section1">
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: navy;"><o:p> </o:p></span></font></p>
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: navy;">I don’t
understand the assertion
that pushing the maintenance load into the CV brings greater
flexibility (nor
the use of the term “flat” in describing the CV, which is just an
obfuscated inheritance tree). Maintaining the CV directly has now been
demonstrated as providing plenty of flexibility to screw up the
inheritance
hierarchy of the terms, but that’s not a good thing, and doesn’t
seem inherently more flexible than doing the maintenance in an XSD. In
either case, the vast majority of changes one is likely to make are
along the
lines of adding a new instrument type, which would not engender a
change to the
parser code. No, wait, it WOULD engender a change to the parser code
in a
CV-centric world, because the only way to express restriction lists is
through
inheritance instead of simple value restrictions. So, it’s actually
less flexible to maintain the CV.</span></font></p>
</div>
</blockquote>
I was only referring to the support for synonyms. If synonyms are
rejected, then as far as I can tell, maintaining the CV with an
auto-generated schema would be worse than maintaining a hand-rolled
schema by itself. As for changes in the parser code, are you referring
to the semantic validator or to an applied user of the format? In the
former case, the schema would either be edited by hand or be
auto-generated (with updated schema restrictions) after a CV update,
neither of which would require an update to the validator. In the
latter case, we come back to the A, B, and C options for cvParams (not
to mention D, E, and F ;) ). If the cvParams stop at the category
level, then parsers needn't be updated to understand new values. If
cvParams can refer to a value by itself, then the parser is a pain in
the ass to write and it would need to be updated whenever the CV/schema
was updated.<br>
<br>
-Matt<br>
</body>
</html>
|
