Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Global section in CIF headers

The _audit_link items do appear to provide a basis to work on.
Including Brian's suggestions, I think we need the following:

1. Expanding their scope to include any data block (rather than only
ones in the same file)
2. Explicit guidance on how to contruct a unique _audit_block_code
(the pdCIF block_id instructions are a good example)
3. Adding a further enumerated dataitem to use to specify
relationships which may be useful for computer-based applications
(e.g. that the referenced data block is a pattern from a standard
material used to determine the wavelength)

Regarding (1), I can't see how a URL would ever work, given that CIF
files were meant for transfer i.e. the location of a file is likely to
be difficult to pin down unless it is in an archive.  On the other
hand, URI information could be included with the meaning that 'when
this file was produced, the referenced data block was at the following
URI'.

Are there any objections to formalising this into a dictionary
enhancement proposal?  It would probably fit under the recently
proposed procedure for small changes.

best wishes,
James.

On Wed, Sep 9, 2009 at 11:28 PM, Brian McMahon <bm@iucr.org> wrote:
> Note that this is not very different in spirit from the existing AUDIT_LINK
> category in the Core (see
> http://www.iucr.org/__data/iucr/cifdic_html/1/cif_core.dic/Caudit_link.html )
>
> The AUDIT_LINK definition does specify "relationships between data blocks
> in the current CIF", but one could extend it to external data blocks as
> well. If we were to do that, perhaps a case could be made for an additional
> data item _audit_link_block_location that specified a URI of an external
> file (or "." for the current file). We had very long discussions ages back
> about the dangers of providing such transient locations, but it still seems
> the only way that you can usefully do it.
>
>>                        Also, the nature of the relationship could be
>> formalised into an enumerated list to help machine-readability.
>
> That's the difficult bit!
>
> Brian McMahon
>
>
>> Moving on to Brian's suggestion, I think we are overdue for finding a
>> way to describe links between data blocks.  However, using a global_
>> block to do this restricts the description to a single data file.  As
>> an alternative proposal, how about defining a CIF semantic dictionary,
>> with the following two datanames in it?
>>
>> _semantic.block_id
>> _semantic.block_relationship
>>
>> These datanames could be looped inside any datablock order to convey a
>> series of relationships to other datablocks, including those not in
>> the same file e.g.
>>
>> loop_
>>  _semantic.block_id
>>  _semantic.block_relationship
>>
>> |Sydney|090909|JRH         'wavelength determination'
>> |Sydney|080808|VKP        'identical batch of sample'
>> |Sydney|070707|XYZ         'raw powder data'
>> |Sydney|060606|ABC        'Lebail refined structure'
>>
>>
>> In the example I have used a pd_block.id type construction to uniquely
>> identify a datablock.  Also, the nature of the relationship could be
>> formalised into an enumerated list to help machine-readability.
> _________________________________________________________________________
> Brian McMahon                                       tel: +44 1244 342878
> Research and Development Officer                    fax: +44 1244 314888
> International Union of Crystallography            e-mail:  bm@iucr.org
> 5 Abbey Square, Chester CH1 2HU, England
> _______________________________________________
> comcifs mailing list
> comcifs@iucr.org
> http://scripts.iucr.org/mailman/listinfo/comcifs
>



-- 
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148

Reply to: [list | sender only]