November 2001 - tdwg-content

Taxonomic hierarchy in SDD
by Robert A. (Bob) Morris 26 Nov '01

26 Nov '01

Surely there will be other hierarchies than classical taxonomy through which providers wish to offer inheritance. Phylogenetic hierarchies come to mind, for example. If the problem is inheritance, then the standard should provide for that, not for a special case. Success would be measured by the ability of the inheritance mechanisms to provide for the special cases. Bob Morris Steve Shattuck writes: > Date: Tue, 27 Nov 2001 13:35:31 +1100 > From: Steve Shattuck <Steve.Shattuck(a)csiro.au> > To: TDWG-SDD(a)usobi.org > Subject: Taxonomic hierarchy in SDD > > The full taxonomic hierarchy of the included taxa/items certainly must be > supported by the standard (and it will be addressed after we deal with > simple characters, states and items). If the creator of the dataset doesn't > think it's important then they can choose to leave it out; if the user of > the data doesn't think it's important then they can ignore it. This will be > especially important if we intend to support inheritance and compilation up > and down the classification (as has been suggested by several of us). > > Jumping the gun a bit, I would think these relationships would be stored > either as a separate nested set of elements with ID's linking to specific > items, or the items themselves would be nested with parent items containing > their children. > > Steve Shattuck > CSIRO Entomology > biolink(a)ento.csiro.au >

1 0

Re: Morphological Data Representation
by Robert A. (Bob) Morris 26 Nov '01

26 Nov '01

Certainly end users need this and many kinds of information. We believe in integrated applications that discover or know where to find the answers to questions like this. See our toy demo http://www.cs.umb.edu/efg/xml1/DEVELOP/itis/demo.htm (This requires MSIE, but it is perfectly possible---and probably better---to support this kind of thing at the server. I subscribe to the belief that simplicity is superior to complexity, especially since much of the infrastructure now available to XML-based applications means that much of the programming to support gathering information from disparate sources is provided in the toolkits. To pick a field guide at random (or rather, what's at hand): the National Audubon Field Guide to Insects and Spiders has almost no taxonomy above Order (it does mention that the insects are in Class Insecta and Phylum Arthropoda; no mention of Subphylum, Subclass, Superorder, Suborder or other arcana easily found from ITIS). In my experience, field guide books may have a little nod toward taxonomy above Family (or Order if they are meant to be broad) but make no attempt to place the descriptive data in such taxonomy. Electronic descriptive pages vary widely, but those that embed taxonomy in their databases risk errors, excessive and often redundant data, and fragility in the face of taxonomic revisions. I say that if we are talking about descriptive data, we should just stick to descriptive data. Bob Morris Peter Rauch writes: > Date: Mon, 26 Nov 2001 11:22:45 -0800 > From: Peter Rauch <peterr(a)socrates.berkeley.edu> > To: TDWG-SDD(a)usobi.org > Subject: Re: Morphological Data Representation > > On Mon, 26 Nov 2001, Robert A. (Bob) Morris wrote: > > > My feeling is that taxonomic hierarchy is best got by web > > applications from services such as ITIS or other web > > services offering XML. There is a large community of > > descriptive data consumers, e.g. field naturalists, that > > find taxonomic hierarchy generally uninteresting. IMO, > > trying to integrate it with descriptive data actually > > addresses a small group of applications at a cost of added > > complexity. > > "There is a large community of descriptive data consumers, e.g. > field naturalists, that find taxonomic hierarchy generally > uninteresting." > > Bob, this comment needs a little bit more explanation / > discussion. > > Without arguing _where_ the field naturalist and other consumers > should get their taxonomic hierarchical information, I'd want to > argue that such information is (should be!) anything but > "uninteresting" to many (most?, all?) consumers, in their work > of understanding who is present in their study worlds and why. > > Having access to purported (evolutionary) relationships of their > study organisms focuses a special, valuable, most "interesting" > light on their studies. These users need to find these taxonomic > relationships handily, somewhere. In that context, your question > --Where?-- is probably a fair one to ask. > > Peter >

1 0

Forgot the bloody attachment
by Kevin Thiele 26 Nov '01

26 Nov '01

Forgot the bloody attachment - How many times does one have to put up a message before getting the message through? Oops. Steve Shattuck's pointed out, quite rightly, that we shouldn't fuss too much over the details of the challenge cases before actually taking the challenges. I think it's important to have a bit of an overview of the challenges for some distance ahead of us while working on one challenge in hand, rather than just taking steps one at a time, because it may be that solving one challenge may canalize us into a solution that makes a challenge down the road more difficult. So I suggest we keep a set of challenges in mind while working. But, of course, it'd be a disaster if we couldn't even agree on the challenges before starting to find the solutions! Cheers - k ----- Original Message ----- From: "Kevin Thiele" <kevin.thiele(a)BIGPOND.COM> To: <TDWG-SDD(a)USOBI.ORG> Sent: Sunday, November 25, 2001 9:27 PM Subject: Challenge Cases | Welcome back! | | I actually posted this message a week ago, but my email address has changed | slightly, and the list server rejected me. So here it is again. | | At the Sydney TDWG meeting we agreed that we would continue with the SDD | discussion on this list, but try to keep a tighter focus. The last active | period (about 12 months ago) was an important brainstorm session, but didn't | seem to be very effective at actually getting us to the goal of a workable | standard. | | We decided this time to try working through some challenge cases - real or | made-up instances of descriptive data that need to be accommodated in the | standard. By agreeing first on a +/- complete set of challenges, then | working through the challenge cases in order from simple to difficult, we | should be able to reasonably bound our problem while keeping an overview of | the territory while actually sinking out teeth into the nitty-gritty. | | Attached is my first attempt at a set of challenge cases, presented in +/- | this form to the Sydney meeting. The first challenge case has an exemplar, | the others have not yet. This document as it's worked up will be placed on | the TDWG web site for working reference. As the standard evolves, this will | also be put up on the site, possibly with progressive status indicators for | parts of the standard (e.g. working, proposed, normative - may we one day | get to normative) | | I suggest that we should first add to or modify the list of challenges. | Propose a challenge (with exemplar) to add to the list. Once we are happy | with an approximate list of challenges (keeping in mind that others will | become clear as we proceed, so there's no need to agonise over this step), | we'll start with challenge 1. We'll throw up the challenge, give a week or | so for contributors to propose data structures that can meet the challenge, | then compare and discuss alternate solutions. | | Gregor I think will shortly be posting a summary of the meeting discussions. | We agreed, I believe, that the goal is to provide a standard that can | adequately address the descriptive data requirements (ie be a superset) of | all existing programs (e.g. Lucid, DELTA, DELTA Access, Biolink) but not be | limited to existing programs. It should be able to function as an | interchange standard, but should not be limited to that. Bob Morris agreed | to provide shortly a discussion on interchange vs interoperability standards | and conflicts that may arise in trying to allow for both goals. We agreed | that XML will be the basis for the standard. | | May the force be with us! | | Cheers - k

1 0

Re: Morphological Data Representation
by Mauro J. Cavalcanti 26 Nov '01

26 Nov '01

Steve Shattuck wrote: > Leigh's comments are good and worth a detailed look. His > model/representation/syntax (or whatever you want to call it) of the same > data I used (see http://www.bath.ac.uk/~ccslrd/delta/lep.xml) is exactly the > kind of thing I had in mind. Does his representation make more sense than > the one I proposed? What are the strengths/weaknesses of our approaches. > Does one allow us to get to where we want to be? Again, I don't think the Shattuck's and Dodd's proposals indeed seem basically identical (with XDELTA deserving priority, since it has been presented first; it also seems a little bit more detailed than Shattuck's proposal). What I miss is an integration of the morphological data representation with the representation of the taxonomic hierarchy (that has never been properly dealt with by DELTA) in a single XML format for the purpose of storing and exchanging taxonomic datasets. Gilmour's "Taxonomic Markup Language" (http://www.albany.edu/~gilmr/pubxml/ ) could provide a good start in this direction. I would appreciate very much any comments in this connection. Regards, -- + - - - - - - - - - - - - Mauro J. Cavalcanti - - - - - - - - - - - - + | Setor de Paleovertebrados, Departamento de Geologia e Paleontologia | | Museu Nacional do Rio de Janeiro | | Quinta da Boa Vista, 20940-040, Rio de Janeiro, RJ, BRASIL | | E-mail: maurobio(a)acd.ufrj.br | | Home Page: http://www.maurobio.cjb.net | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + "Life is complex. It consists of real and imaginary parts."

1 0

Re: Morphological Data Representation
by Robert A. (Bob) Morris 26 Nov '01

26 Nov '01

Mauro J. Cavalcanti writes: > Date: Mon, 26 Nov 2001 15:21:52 -0200 > From: "Mauro J. Cavalcanti" <maurobio(a)acd.ufrj.br> > To: TDWG-SDD(a)usobi.org > Subject: Re: Morphological Data Representation > > ... > > What I miss is an integration of the morphological data representation with the > representation of the taxonomic hierarchy (that has never been properly dealt > with by DELTA) in a single XML format for the purpose of storing and exchanging > taxonomic datasets. Gilmour's "Taxonomic Markup Language" > (http://www.albany.edu/~gilmr/pubxml/ ) could provide a good start in this > direction. > > I would appreciate very much any comments in this connection. My feeling is that taxonomic hierarchy is best got by web applications from services such as ITIS or other web services offering XML. There is a large community of descriptive data consumers, e.g. field naturalists, that find taxonomic hierarchy generally uninteresting. IMO, trying to integrate it with descriptive data actually addresses a small group of applications at a cost of added complexity.

1 0

Re: Morphological Data Representation
by unknown＠example.com 26 Nov '01

26 Nov '01

First, I see Kevin has proposed a process slightly different to the one I started on Friday. I would suggest that we focus on one of these rather than running both at the same time. I don't think it matter which one we follow as they both have pros and cons. My idea was to start simple and build as we go while Kevin's is to scope the project first then fill in the details. Any strong views on the process. Guillaume commented that he's "always surprised seeing people recommend using proprietary stuff" in response to my suggestion of using Microsoft's XML Notepad (which, by the way, is actually free). The point I was trying to make was that XML can get complicated very quickly and using an XML view (of any sort) is better than using a text editor. Nothing more. He also commented that my example "was closely related to delta (as xdelta), whereas everyone seems to agree on building something from scratch". I fully agree, but I would suggest that DELTA has it basically right and that whatever we develop will look suspiciously like DELTA. For years taxonomists have talked about things called "characters" with "states" and have used these to build "descriptions" (= DELTA attributes). DELTA is firmly founded in taxonomic practices and since this is driving this process I would be surprised if they diverge too far. In other words there's a reason DELTA has been as broadly accepted as it has and we shouldn't ignore this. Guillaume's final comment, about the use of XML elements and attributes, is important but I still think it can wait. There often isn't a clear distinction between information that "has real-world meaning" and that which is "modelling artefacts." ["One person's data is another person's metadata."] The fact that "default XSLT transformation enforces this by outputting elements contents and ignoring attributes" is too application specific. Many people process XML using DOM tools and they shouldn't be constrained just because XSLT does it another way. Leigh's comments are good and worth a detailed look. His model/representation/syntax (or whatever you want to call it) of the same data I used (see http://www.bath.ac.uk/~ccslrd/delta/lep.xml) is exactly the kind of thing I had in mind. Does his representation make more sense than the one I proposed? What are the strengths/weaknesses of our approaches. Does one allow us to get to where we want to be? Again, I don't think the exact syntax is important at this stage. For example, both models describe the meaning of the numbers present in item descriptions for numeric characters, Leigh as "<value start="0.5" end="0.55" />" and myself as "<CodedState StateID=C3S1 Value=0.5 /> <CodedState StateID=C3S2 Value=0.55 />" with the meaning stored with the state rather than the item description. At the syntax-level these are very different but at the modelling-level they are the same - the same information is being managed (and both differ from the current DELTA-standard in this regard). We will need to work on the syntax but let's get the model agreed to first, then worry about specific syntax. >However, we must agree on model extend: will it concerns only concept >description (aka: characters) or also case description (aka: items) ? IMHO, >only the first one can be generalized, or we'll have to validate the case >description twice: against a generic model and against its concept. > >For using an example, if i have a description of the characters of >Pociloporidae familiy, and a description of the items of Pociloporidae >family, i'll have to make sure characters are really characters (validating >against generic character model), to make sure items are really items >(validating against generic items model), and make sure Pociloporidae items >are really Pociloporida (validating items against characters). I would prefer >to have only to validate characters against a generic character model, and >validate items against characters, meaning using a character description as a >suitable model for items description. I believe this misses the goals of this project in a number of important ways and we should avoid going down this path. It seems to mix the (i) processing of the data with (ii) the data representation with (iii) taxonomic work practices. I'm very uncomfortable going there. Finally, Peter's concerns are important for the next step, expanding the proposed representation to include information not currently managed. One of the strong recommendations from SDD Round 1 was to manage raw data. This needs to be housed under the summarized data (in this case, the actual measurements under the ratios). We WILL need to do this eventually. Peter also pointed out possibly our largest challenge. He noted that "having clear spots in wings is not very precise if the data is to be comparable beyond the group in question - which I suppose is part of the goal." At every TDWG meeting I've been to we decide that we can't build standards for specific character values and yet at every TDWG meeting I've been to we try to build standards for specific character values. We need to build mechanisms to allow sharing of character lists across projects IF THOSE PROJECTS WANT TO USE THIS FEATURE. If projects don't want to share character lists, for what ever reason, then they won't not matter how important we think it is to do so. <soapbox on> I think this focus on "standard character lists" is very much a "plant thing." In animals it would never occur to me to use "clear spots in wings" for anything other than the local context for which it was established. No one would suggest that "clear spots in wings" in bees has anything to do with "clear spots in wings" in butterflies and trying to use a single character coding for this would receive limited support at best. I think the problem is that it's common to talk about "identifying a plant" but very rare to talk about "identifying an animal." There are no "faunas" that are equivalent to "floras." This very fundamental difference between plants and animals and the way people view them has a huge impact on this very development - it's one of the reason's that the botanical community has accepted DELTA much more strongly than the zoological community. While a "global flora" is a completely reasonable goal, a "global fauna" isn't even a faint blip on distant radar. Zoologists work in relative isolation compared to botanists and have very different work practices and needs. Meeting the needs of both of these communities will be a significant challenge, one I'm not sure we can meet in a single set of tools. <soapbox off> Thanks, Steve Steve Shattuck CSIRO Entomology steve.shattuck(a)csiro.au

1 0

Re: Morphological Data Representation
by Peter Rauch 26 Nov '01

26 Nov '01

On Mon, 26 Nov 2001, Robert A. (Bob) Morris wrote: > My feeling is that taxonomic hierarchy is best got by web > applications from services such as ITIS or other web > services offering XML. There is a large community of > descriptive data consumers, e.g. field naturalists, that > find taxonomic hierarchy generally uninteresting. IMO, > trying to integrate it with descriptive data actually > addresses a small group of applications at a cost of added > complexity. "There is a large community of descriptive data consumers, e.g. field naturalists, that find taxonomic hierarchy generally uninteresting." Bob, this comment needs a little bit more explanation / discussion. Without arguing _where_ the field naturalist and other consumers should get their taxonomic hierarchical information, I'd want to argue that such information is (should be!) anything but "uninteresting" to many (most?, all?) consumers, in their work of understanding who is present in their study worlds and why. Having access to purported (evolutionary) relationships of their study organisms focuses a special, valuable, most "interesting" light on their studies. These users need to find these taxonomic relationships handily, somewhere. In that context, your question --Where?-- is probably a fair one to ask. Peter

1 0

Re: Morphological Data Representation
by Robert A. (Bob) Morris 25 Nov '01

25 Nov '01

Steve Shattuck writes: > Date: Mon, 26 Nov 2001 12:31:40 +1100 > From: Steve Shattuck <Steve.Shattuck(a)csiro.au> > To: TDWG-SDD(a)usobi.org > Subject: Re: Morphological Data Representation > > First, I see Kevin has proposed a process slightly different to the one I > started on Friday. I would suggest that we focus on one of these rather > than running both at the same time. I don't think it matter which one we > follow as they both have pros and cons. My idea was to start simple and > build as we go while Kevin's is to scope the project first then fill in the > details. Any strong views on the process. The "data challenges" process was what was agreed in Sydney. Also, it corresponds closely to processes generally regarded as successful in software design, namely Use Case analysis, though it focuses on the use and not the user (in the sense of both human and software). > > Guillaume commented that he's "always surprised seeing people recommend > using proprietary stuff" in response to my suggestion of using Microsoft's > XML Notepad (which, by the way, is actually free). The point I was trying > to make was that XML can get complicated very quickly and using an XML view > (of any sort) is better than using a text editor. Nothing more. Also, MSIE is a reasonable XML viewer, albeit not an editor. > > He also commented that my example "was closely related to delta (as xdelta), > whereas everyone seems to agree on building something from scratch". I > fully agree, but I would suggest that DELTA has it basically right and that > whatever we develop will look suspiciously like DELTA. For years > taxonomists have talked about things called "characters" with "states" and > have used these to build "descriptions" (= DELTA attributes). DELTA is > firmly founded in taxonomic practices and since this is driving this process > I would be surprised if they diverge too far. In other words there's a > reason DELTA has been as broadly accepted as it has and we shouldn't ignore > this. In Sydney it was agreed that DELTA experience and functionality should not be ignored, i.e. we should not start from scratch. [I don't happen to agree with that because of the large community outside TDWG that is already heavily involved in descriptive data if only informally. But it is what was decided, and it does leverage the experience of most of SDD. The trick will be to not arrive at something that only models DELTA] > > Guillaume's final comment, about the use of XML elements and attributes, is > important but I still think it can wait. There often isn't a clear > distinction between information that "has real-world meaning" and that which > is "modelling artefacts." ["One person's data is another person's > metadata."] The fact that "default XSLT transformation enforces this by > outputting elements contents and ignoring attributes" is too application > specific. Many people process XML using DOM tools and they shouldn't be > constrained just because XSLT does it another way. Not only can it wait, but these things are possibly technical enough that they shouldn't be initially in this mailing list. We are nearly finished an installation of vBulletin forum software and will offer to operate a forum off this list for discussion of the technical bits. > > Leigh's comments are good and worth a detailed look. His > model/representation/syntax (or whatever you want to call it) of the same > data I used (see http://www.bath.ac.uk/~ccslrd/delta/lep.xml) is exactly the > kind of thing I had in mind. Does his representation make more sense than > the one I proposed? What are the strengths/weaknesses of our approaches. > Does one allow us to get to where we want to be? Again, I don't think the > exact syntax is important at this stage. For example, both models describe > the meaning of the numbers present in item descriptions for numeric > characters, Leigh as "<value start="0.5" end="0.55" />" and myself as > "<CodedState StateID=C3S1 Value=0.5 /> <CodedState StateID=C3S2 Value=0.55 > />" with the meaning stored with the state rather than the item description. > At the syntax-level these are very different but at the modelling-level they > are the same - the same information is being managed (and both differ from > the current DELTA-standard in this regard). We will need to work on the > syntax but let's get the model agreed to first, then worry about specific > syntax. > > > >However, we must agree on model extend: will it concerns only concept > >description (aka: characters) or also case description (aka: items) ? IMHO, > >only the first one can be generalized, or we'll have to validate the case > >description twice: against a generic model and against its concept. > > To the extent these are separable, there would probably be less dispute about character representation. Probably this means that lots of case description models have to fit on the same character model. > >For using an example, if i have a description of the characters of > >Pociloporidae familiy, and a description of the items of Pociloporidae > >family, i'll have to make sure characters are really characters (validating > >against generic character model), to make sure items are really items > >(validating against generic items model), and make sure Pociloporidae items > >are really Pociloporida (validating items against characters). I would > prefer > >to have only to validate characters against a generic character model, and > >validate items against characters, meaning using a character description as > a > >suitable model for items description. As a not biologist, this sounds right to me. > > I believe this misses the goals of this project in a number of important > ways and we should avoid going down this path. It seems to mix the (i) > processing of the data with (ii) the data representation with (iii) > taxonomic work practices. I'm very uncomfortable going there. > > > Finally, Peter's concerns are important for the next step, expanding the > proposed representation to include information not currently managed. One > of the strong recommendations from SDD Round 1 was to manage raw data. This > needs to be housed under the summarized data (in this case, the actual > measurements under the ratios). We WILL need to do this eventually. > > Peter also pointed out possibly our largest challenge. He noted that "having > clear spots in wings is not very > precise if the data is to be comparable beyond the group in question - which > I suppose is part of the goal." At every TDWG meeting I've been to we > decide that we can't build standards for specific character values and yet > at every TDWG meeting I've been to we try to build standards for specific > character values. We need to build mechanisms to allow sharing of character > lists across projects IF THOSE PROJECTS WANT TO USE THIS FEATURE. If > projects don't want to share character lists, for what ever reason, then > they won't not matter how important we think it is to do so. I agree with this. Whether sharing character lists matters may be a function of the purpose of the list. For example, paper field guides to a given group of taxa often have a far greater commonality of description of characters than they do of characters. And they often come equipped with a character metadata section that explains how to use the characters. > > <soapbox on> > I think this focus on "standard character lists" is very much a "plant > thing." In animals it would never occur to me to use "clear spots in wings" > for anything other than the local context for which it was established. No > one would suggest that "clear spots in wings" in bees has anything to do > with "clear spots in wings" in butterflies and trying to use a single > character coding for this would receive limited support at best. I think > the problem is that it's common to talk about "identifying a plant" but very > rare to talk about "identifying an animal." There are no "faunas" that are > equivalent to "floras." This very fundamental difference between plants and > animals and the way people view them has a huge impact on this very > development - it's one of the reason's that the botanical community has > accepted DELTA much more strongly than the zoological community. While a > "global flora" is a completely reasonable goal, a "global fauna" isn't even > a faint blip on distant radar. Zoologists work in relative isolation > compared to botanists and have very different work practices and needs. > Meeting the needs of both of these communities will be a significant > challenge, one I'm not sure we can meet in a single set of tools. > <soapbox off> > > Thanks, Steve > > Steve Shattuck > CSIRO Entomology > steve.shattuck(a)csiro.au >

1 0

Challenge Cases
by Kevin Thiele 25 Nov '01

25 Nov '01

Welcome back! I actually posted this message a week ago, but my email address has changed slightly, and the list server rejected me. So here it is again. At the Sydney TDWG meeting we agreed that we would continue with the SDD discussion on this list, but try to keep a tighter focus. The last active period (about 12 months ago) was an important brainstorm session, but didn't seem to be very effective at actually getting us to the goal of a workable standard. We decided this time to try working through some challenge cases - real or made-up instances of descriptive data that need to be accommodated in the standard. By agreeing first on a +/- complete set of challenges, then working through the challenge cases in order from simple to difficult, we should be able to reasonably bound our problem while keeping an overview of the territory while actually sinking out teeth into the nitty-gritty. Attached is my first attempt at a set of challenge cases, presented in +/- this form to the Sydney meeting. The first challenge case has an exemplar, the others have not yet. This document as it's worked up will be placed on the TDWG web site for working reference. As the standard evolves, this will also be put up on the site, possibly with progressive status indicators for parts of the standard (e.g. working, proposed, normative - may we one day get to normative) I suggest that we should first add to or modify the list of challenges. Propose a challenge (with exemplar) to add to the list. Once we are happy with an approximate list of challenges (keeping in mind that others will become clear as we proceed, so there's no need to agonise over this step), we'll start with challenge 1. We'll throw up the challenge, give a week or so for contributors to propose data structures that can meet the challenge, then compare and discuss alternate solutions. Gregor I think will shortly be posting a summary of the meeting discussions. We agreed, I believe, that the goal is to provide a standard that can adequately address the descriptive data requirements (ie be a superset) of all existing programs (e.g. Lucid, DELTA, DELTA Access, Biolink) but not be limited to existing programs. It should be able to function as an interchange standard, but should not be limited to that. Bob Morris agreed to provide shortly a discussion on interchange vs interoperability standards and conflicts that may arise in trying to allow for both goals. We agreed that XML will be the basis for the standard. May the force be with us! Cheers - k

1 0

Re: Morphological Data Representation
by Leigh Dodds 23 Nov '01

23 Nov '01

This nicely demonstrates the point that the syntax is only a way to encode a particular model. I'd previously cast the same basic Lepidoptera data into XML (with some additional data, such as images) using XDelta: http://www.bath.ac.uk/~ccslrd/delta/lep.xml I'm sure the following is wrong in places and/or overly simplistic, and deliberately so: A Character has - a Character Type (one of Ordered or Unordered or Real, or ...) - a Character Identifier (a number) - a Short Description (free text) - a Long Description (free text) - an Order Identifier (a number) - a State Descriptor (free text) A State has - a State Value (free text) - a State Identifier (a number) - an Order Identifier An Item has - An Item Type (free text) - An Item Identifier (a number) - A Description (free text) - One or more Characteristics (observed values of states for specific characters) Characters describe a list of properties for some Type of Thing might have. States describe the list of (observed) values of that property for a specific Type of Thing (avoiding the word Class as it's an overloaded term). An Item is the specific instances of those properties, with some specific Thing. What did I get wrong? L.

1 0