- tdwg-content - lists.tdwg.org

Re: Challenge 1
by Cornelia Buchen-Osmond 03 Dec '01

03 Dec '01

I don't think that DELTA has given up too soon to "decide whether ease (as opposed to possibility) of producing documents is a more important design goal than ease of describing structures suitable for searching, integration with other structures such as those emerging from the Accessions groups efforts for specimen records, molecular data, and other data from sources other than those in a descriptive database". When starting with a database you often don't know, what is needed to suit best the demands. Text comments are very helpful to get to the first basis and the developer of the database has to integrate those comments later on into well structured language that is searchable. Dr Cornelia Büchen-Osmond Biosphere 2 Center 32540 S. Biosphere Road P.O. Box 689 Oracle, AZ 85623 U.S.A. Phone +1 (520) 896-5126 Fax +1 (520) 896-6429 email: buchen(a)bio2.columbia.edu ICTVdB - The Universal Virus Database http://www.ncbi.nlm.nih.gov/ICTVdb/ http://www.ictvdb.iacr.ac.uk/ http://www1.im.ac.cn/ictvdb/welcome.htm ----- Original Message ----- From: "Robert A. (Bob) Morris" <ram(a)CS.UMB.EDU> To: <TDWG-SDD(a)USOBI.ORG> Sent: Sunday, December 02, 2001 6:55 AM Subject: Re: Challenge 1 > I don't believe that minimizing markup is a desirable design goal. The > usual argument for it is that it makes the document easier for humans to read, > but the plain fact is that XML is rarely written or read by humans > except when they are either debugging or designing. If there really > are no natural tags to surround text in a particular case, it is > common to just surround it with <text> </text>. > > In this case, as is common, the tension arising is that between > articulating object structure and articulating document structure. As > I now understand DELTA, it devotes quite a bit of energy to ease of > producing documents, and maybe this group has to soon decide > whether ease (as opposed to possibility) of producing documents is a > more important design goal than ease of describing structures suitable > for searching, integration with other structures such as those > emerging from the Accessions groups efforts for specimen records, > molecular data, and other data from sources other than those in a > descriptive database. Resolving this tension with a compromise could > make /both/ enterprises hard instead of just one. My own bias, and I > think that of XML, is that it is easier to compute documents > given rigorous structure than the other way round. > > > > Kevin Thiele writes: > > Date: Sat, 1 Dec 2001 22:12:56 +1100 > > From: Kevin Thiele <kevin.thiele(a)bigpond.com> > > To: TDWG-SDD(a)usobi.org > > Subject: Re: Challenge 1 > > > > ----- Original Message ----- > > From: "Jim Croft" <jrc(a)ANBG.GOV.AU> > > To: <TDWG-SDD(a)USOBI.ORG> > > Sent: Saturday, December 01, 2001 8:30 AM > > Subject: Re: Challenge 1 > > > > > > | Kevin wrote: > > | >I've taken the route of marking up a textual description, using a minimum > > of > > | >tags. It seems to me that a description comprises a series of features > > with > > | >values. I've used mixed markup because I wanted to have the mimimum > > | >tagging and make maximum use of the text. > > | > > | Although XML allows mixed content such as Kevin's: > > | <Feature><Name>spines</Name>, not developing at each node, > > | <Feature Name="Length" MinValue="0">to c. > > | <MaxValue>1</MaxValue><Units>cm</Units> long</Feature> > > | </Feature> > > | and such a document can be validated against a schema, apart from being > > | untidy and inelegant, mixed content can pose certain problems when > > | attempted to be loaded into a relational database; this is probably not > > | going to impress people like Gregor. > > | > > | Can we agree that although mixed content XML is quite allowable, we are > > | going to try and avoid it in the SDD context? > > > > > > Hey, who said we should aim to make life easier for Gregor? I regard it as a > > life ambition to make things harder for software developers, especially > > those who insist on cramming mother nature kicking and screaming into a > > database! > > > > The mixed content of my suggestion is the thing I worry about most. But if > > there are advantages to mixed content (and it seems to me there are) then I > > think these should be weighed against the difficulty of dealing with it. > > Once we have more alternate solutions to challenge 1 we can deal with the > > advantages/disadvantages of particular solutions. I wouldn't like to > > preclude mixed content at this early stage - let's knock it on the head a > > bit further down the track. > > > > Cheers - k > > >

1 0

Re: Challenge 1
by Jim Croft 03 Dec '01

03 Dec '01

>The mixed content of my suggestion is the thing I worry about most. But if >there are advantages to mixed content (and it seems to me there are) then I >think these should be weighed against the difficulty of dealing with it. I am not yet convinced there are real advantages in mixed content, other than allowing the reproduction of a block of text closer to what was actually written in a prior publication. If the information can be represented structurally without resorting to mixed content then I think this is what we should do. However, it might be ok to defer banning mixed content outright until we are convinced we have a structure that caters for all our needs. My gut feeling is that the structure will not fully cater for our needs as long as there is mixed content. But we shall see... jim ~ Jim Croft ~ jrc(a)anbg.gov.au ~ 02-62465500 ~ www.anbg.gov.au/jrc/ ~

1 0

Re: Challenge 1
by Robert A. (Bob) Morris 02 Dec '01

02 Dec '01

I don't believe that minimizing markup is a desirable design goal. The usual argument for it is that it makes the document easier for humans to read, but the plain fact is that XML is rarely written or read by humans except when they are either debugging or designing. If there really are no natural tags to surround text in a particular case, it is common to just surround it with <text> </text>. In this case, as is common, the tension arising is that between articulating object structure and articulating document structure. As I now understand DELTA, it devotes quite a bit of energy to ease of producing documents, and maybe this group has to soon decide whether ease (as opposed to possibility) of producing documents is a more important design goal than ease of describing structures suitable for searching, integration with other structures such as those emerging from the Accessions groups efforts for specimen records, molecular data, and other data from sources other than those in a descriptive database. Resolving this tension with a compromise could make /both/ enterprises hard instead of just one. My own bias, and I think that of XML, is that it is easier to compute documents given rigorous structure than the other way round. Kevin Thiele writes: > Date: Sat, 1 Dec 2001 22:12:56 +1100 > From: Kevin Thiele <kevin.thiele(a)bigpond.com> > To: TDWG-SDD(a)usobi.org > Subject: Re: Challenge 1 > > ----- Original Message ----- > From: "Jim Croft" <jrc(a)ANBG.GOV.AU> > To: <TDWG-SDD(a)USOBI.ORG> > Sent: Saturday, December 01, 2001 8:30 AM > Subject: Re: Challenge 1 > > > | Kevin wrote: > | >I've taken the route of marking up a textual description, using a minimum > of > | >tags. It seems to me that a description comprises a series of features > with > | >values. I've used mixed markup because I wanted to have the mimimum > | >tagging and make maximum use of the text. > | > | Although XML allows mixed content such as Kevin's: > | <Feature><Name>spines</Name>, not developing at each node, > | <Feature Name="Length" MinValue="0">to c. > | <MaxValue>1</MaxValue><Units>cm</Units> long</Feature> > | </Feature> > | and such a document can be validated against a schema, apart from being > | untidy and inelegant, mixed content can pose certain problems when > | attempted to be loaded into a relational database; this is probably not > | going to impress people like Gregor. > | > | Can we agree that although mixed content XML is quite allowable, we are > | going to try and avoid it in the SDD context? > > > Hey, who said we should aim to make life easier for Gregor? I regard it as a > life ambition to make things harder for software developers, especially > those who insist on cramming mother nature kicking and screaming into a > database! > > The mixed content of my suggestion is the thing I worry about most. But if > there are advantages to mixed content (and it seems to me there are) then I > think these should be weighed against the difficulty of dealing with it. > Once we have more alternate solutions to challenge 1 we can deal with the > advantages/disadvantages of particular solutions. I wouldn't like to > preclude mixed content at this early stage - let's knock it on the head a > bit further down the track. > > Cheers - k >

1 0

Re: Challenge 1
by Kevin Thiele 01 Dec '01

01 Dec '01

----- Original Message ----- From: "Jim Croft" <jrc(a)ANBG.GOV.AU> To: <TDWG-SDD(a)USOBI.ORG> Sent: Saturday, December 01, 2001 8:30 AM Subject: Re: Challenge 1 | Kevin wrote: | >I've taken the route of marking up a textual description, using a minimum of | >tags. It seems to me that a description comprises a series of features with | >values. I've used mixed markup because I wanted to have the mimimum | >tagging and make maximum use of the text. | | Although XML allows mixed content such as Kevin's: | <Feature><Name>spines</Name>, not developing at each node, | <Feature Name="Length" MinValue="0">to c. | <MaxValue>1</MaxValue><Units>cm</Units> long</Feature> | </Feature> | and such a document can be validated against a schema, apart from being | untidy and inelegant, mixed content can pose certain problems when | attempted to be loaded into a relational database; this is probably not | going to impress people like Gregor. | | Can we agree that although mixed content XML is quite allowable, we are | going to try and avoid it in the SDD context? Hey, who said we should aim to make life easier for Gregor? I regard it as a life ambition to make things harder for software developers, especially those who insist on cramming mother nature kicking and screaming into a database! The mixed content of my suggestion is the thing I worry about most. But if there are advantages to mixed content (and it seems to me there are) then I think these should be weighed against the difficulty of dealing with it. Once we have more alternate solutions to challenge 1 we can deal with the advantages/disadvantages of particular solutions. I wouldn't like to preclude mixed content at this early stage - let's knock it on the head a bit further down the track. Cheers - k

1 0

Re: Thought and a Question
by Kevin Thiele 01 Dec '01

01 Dec '01

----- Original Message ----- From: "Leigh Dodds" <ldodds(a)INGENTA.COM> To: <TDWG-SDD(a)USOBI.ORG> Sent: Friday, November 30, 2001 8:27 PM Subject: Thought and a Question | I'd like to suggest, again, that the solutions for the challenges | should be presented as simple data models. Syntax can come later | (and may fall naturally out of the model). Leigh - can you give us an example of your solution to challenge 1 then?

1 0

Re: Challenge 1
by Jim Croft 01 Dec '01

01 Dec '01

Kevin wrote: >I've taken the route of marking up a textual description, using a minimum of >tags. It seems to me that a description comprises a series of features with >values. I've used mixed markup because I wanted to have the mimimum >tagging and make maximum use of the text. Although XML allows mixed content such as Kevin's: <Feature><Name>spines</Name>, not developing at each node, <Feature Name="Length" MinValue="0">to c. <MaxValue>1</MaxValue><Units>cm</Units> long</Feature> </Feature> and such a document can be validated against a schema, apart from being untidy and inelegant, mixed content can pose certain problems when attempted to be loaded into a relational database; this is probably not going to impress people like Gregor. Can we agree that although mixed content XML is quite allowable, we are going to try and avoid it in the SDD context? jim ~ Jim Croft ~ jrc(a)anbg.gov.au ~ 02-62465500 ~ www.anbg.gov.au/jrc/ ~

1 0

Re: Character hierarchies
by Jim Croft 01 Dec '01

01 Dec '01

>The other qualifiers (misinterps etc) aren't in there yet, but will come. >We'll have to be much more sophisticated that in my example, of course. > >Now how about "definately known to be unknown" Very droll... However, Greg and I have discussed this in depth over a bottle of red and have come to the firm conclusion that without the attribute of "often misinterpreted as definitely known to be unknown", and the corresponding "rarely misinterpreted as definitely known to be unknown", accurate representation of author intent in biological descriptions will never be possible... So get to it - we expect to see this in the next software release, real soon now... jim ~ Jim Croft ~ jrc(a)anbg.gov.au ~ 02-62465500 ~ www.anbg.gov.au/jrc/ ~

1 0

Alternate Hierarchies
by Kevin Thiele 30 Nov '01

30 Nov '01

I agree. I've added an issue to challenge case 6 to address this. 6. Remote and local taxon lists a.. remote referencing of hierarchies from master lists e.g. ITIS b.. local definition of hierarchies c.. efficient rearrangement of hierarchies with knowledge changes d.. alternate hierarchies Cheers - k ----- Original Message ----- From: "Jim Croft" <jrc(a)ANBG.GOV.AU> To: <TDWG-SDD(a)USOBI.ORG> Sent: Friday, November 30, 2001 1:15 AM Subject: Re: Document vs. database | > In DELTA, Lucid etc we express alternate hierarchies in alternate documents. | > Do we need to do better than this? | | Let's stop this line of thought right now... | | build one hierachy of characters that works first, THEN consider how to | manage alternatives... | | maybe... | | jim |

1 0

Character hierarchies
by Kevin Thiele 30 Nov '01

30 Nov '01

----- Original Message ----- From: "Jim Croft" <jrc(a)ANBG.GOV.AU> To: <TDWG-SDD(a)USOBI.ORG> Sent: Friday, November 30, 2001 1:03 AM Subject: Re: Document vs. database | Also, in our new model we also want to show more than just presence | or absence of a state. Don't we want to show if it is present/rarely | present/present by misinterpretation/rarely present by | misisnterpretation, etc., and my favourites yet to be implemented as | a character stae attribute: definitely absent, absent by | misinterpretation, unknown, unscored Of course these will come in. In my example, see: <Feature Name="Longevity"><Value>persistent</Value>(rarely<Value Qualifier="rarely">deciduous</Value>)</Feature> The other qualifiers (misinterps etc) aren't in there yet, but will come. We'll have to be much more sophisticated that in my example, of course. Now how about "definately known to be unknown" | > I'm simply suggesting allowing n levels: | > <Leaves> | > <shape> | > <ovate> | > <elliptic> | > <Flowers> | > <colour> | > <blue> | > <red> | | That is where we want to get to do, but echoing Bob's words, what we | are after is the structure that allows us to get to that, giving | people all the appearance of freedom to do what they like but not | actually doing it and imposing a schematic straight jacket on the data. | A schema for the data structure rather than the descriptive data itself. | Like all freedoms, the descriptive data one too must be an illusion or | we wil miss out on on all the creative potential that it offers as the | free spirits among us do theri own thing. But that is another | discussion... :) Sorry, I made a blue with the example. It should have been: <Feature name = "Leaves"> <Feature name = "shape"> <Value>ovate</Value> <Value>elliptic</Value> </Feature> </Feature> <Feature name = "Flowers"> <Feature name = "colour"> <Value>blue</Value> <Value>red</Value> </Feature> </Feature> | There has been a lot of talk about the feature/value paradigm and how | this might be made to represent a biological description and even nested | features in such descriptions... | | At the recent TDWG meeting Richard Pankhurst described something like a | feature/character/value paradigm and at the time I made a note that this | was probalably worth considering in more detail, but so far have not had | the time. | | It probably would mean something like: | | <feature name="leaf" charecter="margin" value="serrate"/> or some But I can't see that "margin" is a thing different in kind from "leaf". Sure, the margin is part of a leaf but equally the leaf is part of the plant, so if you have feature|character|value then you will end up with "leaf" as a feature in one context and a character in another - messy, surely. My example above just has Feature|value. The difference is that a feature is a thing but a value is not (both "leaf" and "margin" are things that can be pointed at, "ovate" and "blue" are not). In the XML tree representation above features are nodes and values are twigs (or leaves if you like - of course, a "twig" would be a node, not a twig (or a leaf) - oh dear, can someone invent a language that isn't a language!) Ditto for Jim's second example: |<feature name="leaf"> | <character name="margin"> | <observation value="serrate" modification="obscurely" state="present" | basis="specimen" reference="Stevens in NGF67432"/> | <observation ..... /> | <observation ..... /> | </character> |</feature> Try interpolating another level in here (e.g. marginal teeth shape) and you get into strife. Whereas with <feature name="leaf"> <feature name="margin"> <value value="serrate" modification="obscurely" state="present" basis="specimen" reference="Stevens in NGF67432"/> <observation ..... /> <observation ..... /> </feature> </feature> We can surely add as many levels as we like. Or can we - here's a challenge - find the simplest way of expanding description 1: "Leaf margin serrate" into description 2: "Leaf margin serrate with forward-pointing teeth". Attempt 1. "Leaf margin serrate" <feature name="leaf"> <feature name="margin"> <value>serrate</value> </feature> </feature> "Leaf margins serrate with forward-pointing teeth" <feature name="leaf"> <feature name="margin"> <feature name = "teething shape"> <value>serrate</value> </feature> <feature name = "teeth orientation">with <value>forward-pointing</value>teeth </feature> </feature> </feature> This requires moving <value="serrate"/> from the node <feature name="margin"> to a new interpolated node <feature name = "teething shape">, so as to keep a rule that <value>s cannot have <feature>s as siblings. An alternative: Attempt 2. "Leaf margins serrate with forward-pointing teeth" <feature name="leaf"> <feature name="margin"> <value>serrate</value> <feature name = "teeth orientation"> <value>forward-pointing</value> </feature> </feature> </feature> breaks this rule. Attempt 2 seems preferable to me in terms of efficiency, but the rule seems somehow important. Of course, restricting ourselves to a 2-level heirarchy a la Lucid and DELTA makes these problems go away, but only because we artificially collapse the levels down and lose the structure: "Leaf margins serrate with forward-pointing teeth" <feature name="leaf margin teething"> <value>serrate</value> </feature> <feature name = "leaf margin teeth orientation"> <value>forward-pointing</value> </feature> I'm getting lost here - can someone help? We've +/- discussed this before, but we need more thinking around real examples such as these. Cheers - k

1 0

Re: Process: Forum software?
by Barringer, Kerry 30 Nov '01

30 Nov '01

Bob, If the group can keep up the current level of activity, a forum would be a great idea. They are really a much more flexible way to work together. Kerry

1 0