[Tcs-lc] Human Readable - the thread formally known as 'Name of NomenCode'

[Sally Hinchcliffe]

Roger wrote:
> Yes I agree that it should be easy to implement but there also needs to 
> be a gradient of implementations. It should be easy to do simple things 
> but it should be possible to do more complex things with a bit more effort.
> 
> I think we are resigned to having some level of normalization in the 
> schema but I imagine this will rarely be used in a single document 
> instance. I am thinking that if we could have 'fancy pointers' of some 
> kind then the work for this reduces greatly. If the pointer in the 
> schema can contain a string summary of the publication, for example, as 
> well as a reference to that publication then in a great many 
> implementations the details of the publication can simply be retrieved 
> with a second call if they are required.

 - yes with fancy pointers (I'm sure Gregor had a more technical 
sounding phrase for these but I quite like it!), everything gets a 
lot simpler all round. And I think this covers Gregor's point re SDD 
as well. It also solves my problem that if the user asks for taxon 1& 
2 they also get taxon 3 & 4 just to make the links come out. 

But can we do it with TCS/LC as it stands now? From my understanding 
the referred to objects (publication references, other taxon 
concepts) have to be included within the instance document & can't be 
available via fancy pointers from somewhere else.
Or have I misread the schema?

Sally

> 
> Sally Hinchcliffe wrote:
> 
> >Roger wrote:
> >  
> >
> >>I am all for readability and it is something I am just sitting down 
> >>    
> >>
> >to 
> >  
> >
> >>look at in the TCS today. This is partially inspired by trying to 
> >>    
> >>
> >put 
> >  
> >
> >>together some instance documents over the weekend. This matter does 
> >>    
> >>
> >not 
> >  
> >
> >>only include field names but also general structure.
> >>
> >>How important do people consider it is to be able to read/hand 
> >>    
> >>
> >craft TCS 
> >  
> >
> >>instances - at least simple one?
> >>    
> >>
> >
> >
> >I vote for readable, but not necessarily hand-writable. Another thing 
> >to look out for is making sure it's easy for programs to generate the 
> >stuff
> >
> >readability enhances acceptance - if the instance documents look 
> >readable then people are more likely to use them, and they will feel 
> >confident that they will be able to troubleshoot any problems.
> >
> >For writability, the main impact is on the wrappers producing the 
> >XML. When we did this in IPNI, producing the data via templates, the 
> >problem was keeping track of references within the document - for 
> >instance references to publications. The way a website like IPNI 
> >serves data up is as a stream of names with a header at the top and a 
> >footer at the bottom. It's easiest if each name and its associated 
> >data can be totally self contained with no need to keep track of a 
> >second set of data that's being referred to internally within the 
> >document. It's not impossible (we did handle references to 
> >publications in the TCS data we served) but the more internal 
> >references there are to keep track of the harder it is. Unfortunately 
> >recent discussion seems to be sending us down the internal reference 
> >root more and more.
> >So from a generator's point of view this is easy (and I think also 
> >more human readable):
> >
> >start stuff - headers etc.
> > - taxonname 1
> >  - interesting facts about taxonname 1
> >  - publication information about taxonname 1
> >  - other names related to taxonname 1
> >- taxonname 2
> > - interesting facts about taxonname 2
> > - publication information about taxonname 2
> > - other names related to taxonname 2
> >end stuff
> >
> >whereas this is hard (but not impossible):
> >
> >start stuff
> > - taxonname 1
> >   - interesting facts about taxonname 1
> >   - taxonname 1 published in reference 1
> >   - taxonname 1 related to taxonname 3
> >- taxonname 2 
> >   - interesting facts about taxonname 2
> >   - taxonname 2 published in reference 2
> >   - taxonname 2 related to taxonname 4
> > - taxonname 3
> >   - interesting facts about taxonname 3
> >   - taxonname 3 published in reference 3
> >- taxonname 4
> >   - interesting facts about taxonname 4
> >   - taxonname 4 published in reference 4
> >- reference 1
> >  - details for reference 1
> >- reference 2
> >  - details for reference 2
> >- reference 3
> >  - details for reference 3
> >- reference 4
> >  - details for reference 4
> >end stuff
> >
> >
> >Of course it may be we're not generating the data in the most 
> >efficient way ...
> >
> >ps my vote would be for NomenclaturalCode. Does exactly what it says 
> >on the tin...
> >Sally
> >
> >*** Sally Hinchcliffe
> >*** Computer section, Royal Botanic Gardens, Kew
> >*** tel: +44 (0)20 8332 5708
> >*** S.Hinchcliffe at rbgkew.org.uk
> >
> >_______________________________________________
> >Tcs-lc mailing list
> >Tcs-lc at ecoinformatics.org
> >http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/tcs-lc
> >
> >  
> >
> 
> -- 
> 
> ==============================================
>  Roger Hyam
> ----------------------------------------------
>  Biodiversity Informatics
>  Independent Web Development 
> ----------------------------------------------
>  http://www.hyam.net  roger at hyam.net
> ----------------------------------------------
>  2 Janefield Rise, Lauder, TD2 6SP, UK.
>  T: +44 (0)1578 722782 M: +44 (0)7890 341847
> ==============================================
> 
> 
> 

*** Sally Hinchcliffe
*** Computer section, Royal Botanic Gardens, Kew
*** tel: +44 (0)20 8332 5708
*** S.Hinchcliffe at rbgkew.org.uk