https://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362002-09-02T17:29:37ZEcoinformatics RedmineEML - Bug #544: issues about storageType and attributeDomainhttps://projects.ecoinformatics.org/ecoinfo/issues/544?journal_id=18582002-09-02T17:29:37ZMatt Jonesjones@nceas.ucsb.edu
<ul></ul><p>Thanks for the comments on these data typing issues, Dan. There are two<br />distinct issues you raised, which I will address separately:</p>
<p>1) Enumerated domain doesn't allow a simple list without definitions</p>
<pre><code>This is true, and intentional. When data are distributed, it is critical to <br /> know the definitions for the string values that are present in the data <br /> entity. String values or enumerated lists are generally codes that represent <br /> some type of measurement (e.g., HIGH, MEDIUM, LOW), or are names of <br /> sampling locations (e.g., SUBPLOT4). <br /> In either case, it is critical to have the definition. From a data re-use<br /> or data preservation perspective, can you show a case where it would be <br /> acceptable to not have a definition of an enumerated value? If so, I would<br /> agree that we should consider relaxing this requirement, but for now I think <br /> it is a fundamental part of the definition of an enumerated attribute.</code></pre>
<p>2) XML Schema data types used in storageType overlap with attributeDomain</p>
<pre><code>Also true, but the two fields serve different purposes. <br /> The storageType of an attribute is an indication of the type that might be <br /> used to represent the value in a data management system, such as <br /> a database or programming language. It is not actually an <br /> expression of the true domain, as it may in fact be defined slightly <br /> differently than the attributeDomain (e.g., storageType might be "character" <br /> while the domain might be a restricted list of character values).</code></pre>
<pre><code>That we recommend XML Schema Datatypes (which allow restrictions) for the <br /> storageType does not change the need for an independent specification of the <br /> domain. If someone were to use a different type system for the storageType, <br /> especially one which didn't have the restriction capabilities that XML Schema <br /> Datatypes does, then the elimination of attributeDomain would be problematic.<br /> So, basically, attributeDomain is a required expression of the domain, while<br /> storageType is an optional expression of the likely type from some <br /> (hopefully common) type system (e.g., Oracle datatypes, Java datatypes,<br /> XML Schema data types). One might think of storageType as a hint to <br /> automated processing systems as to how one might represent the values of <br /> the attribute. storageType was originally repeatable, and one might<br /> argue that it should be repeatable so that the type from multiple systems<br /> can be indicated. I think that would be a positive change.</code></pre>
<p>In summary, although you make cogent points, I don't think that we should make<br />substantial changes to the model at this time. I will, however, revise the<br />schemas to try to clarify the documentation with respect to these issues, and to<br />make storageType repeatable. Comments? In the absence of further comments,<br />I'll close this bug this week. Thanks.</p> EML - Bug #544: issues about storageType and attributeDomainhttps://projects.ecoinformatics.org/ecoinfo/issues/544?journal_id=18592002-09-05T23:34:06ZMatt Jonesjones@nceas.ucsb.edu
<ul></ul><p>Note from conference call:</p>
<p>some people think unit and attributeDomain should be optional, or that we need a<br />good default value if they are required. For example, a default value for<br />"unit" would be "undefined", and a default value for the attributeDomain would<br />be a textDomain that matches a pattern of ".*". Need to figure out what the heck<br />"dimensionless" is in STMML and how it relates to comment fields and stuff like<br />that that aren't really data. I prefer the latter (required but with sensible<br />defaults). Need a decision on this. Hopefully during tomorrow's conference call.</p> EML - Bug #544: issues about storageType and attributeDomainhttps://projects.ecoinformatics.org/ecoinfo/issues/544?journal_id=18602002-09-09T09:05:29ZMatt Jonesjones@nceas.ucsb.edu
<ul></ul><p>OK, we reached a decision on the conference call. Create a unit "undefined" <br />that is the default for the "unit" field, and keep unit required. Keep<br />attribute domain required, but make sure that; it also has a default of any<br />string as the domain (basically, a textDomain with patter ".*"). I'll need to<br />look into how to implement these decisions.</p> EML - Bug #544: issues about storageType and attributeDomainhttps://projects.ecoinformatics.org/ecoinfo/issues/544?journal_id=18612002-09-11T21:57:32ZMatt Jonesjones@nceas.ucsb.edu
<ul></ul><p>Chad -- can you handle these fixes for this bug? You're pretty familiar with<br />the issues and the proposed solution, and I'm getting slammed before my trip. <br />It has a better chance of getting done on your plate than on mine. That ok? <br />Just need to define the "undefined" unit and the default attributeDomain (".*").</p> EML - Bug #544: issues about storageType and attributeDomainhttps://projects.ecoinformatics.org/ecoinfo/issues/544?journal_id=18622002-09-11T22:27:01ZChad Berkleyberkley@nceas.ucsb.edu
<ul></ul><p>made the default of unit "undefined". made attributeDomain optional but I put<br />in the docs that if the element is omitted, the domain of the attribute is<br />assumed to be the regular expression (.*).</p> EML - Bug #544: issues about storageType and attributeDomainhttps://projects.ecoinformatics.org/ecoinfo/issues/544?journal_id=18632013-03-27T21:14:36ZRedmine Admin
<ul></ul><p>Original Bugzilla ID was 544</p>