[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: Draft JSON specification, round 2
- Subject: Re: Draft JSON specification, round 2
- From: James Hester <jamesrhester@xxxxxxxxx>
- Date: Thu, 20 Apr 2017 17:48:09 +1000
- DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;h=mime-version:in-reply-to:references:from:date:message-id:subject:to;bh=yF65M/z+kcMx1Q+DtAR3LV6WrgPJ9YCOjkpeuSVqnXc=;b=nMp7U4+Xm8YxC+9z1uqFmHtUDc+NazcassHUNCVao4K58hpA7/4LeGMBbJzYUb+KxIia6NVxTvn5J5eMYMNVRd3lG9WoW5s6Q7hH3O/kxtgmGIox0od74QSpDSJqSXAaQa0Yp3t8eVHA2xL3PrakVpUfv5ApOVNTinHxq2VpgQ6wnXei5Jc+hXjR7n/ET9+cUgGKkXQzT4/DNnpwLAePQ2+Atlxx3T0VkC2tsj7kqCtwg0szOCSP46UBh5D7Z1IkseRjTWYaMRcBg+Qz9eRVwJRq17Qh2/4agwjFPnxyGtcWWag29fkWOZ0XgKP/nZ4RYl4PvjnITcWyE6nSkYo/iw==
- In-Reply-To: <da68f60e-dd23-8caa-7acd-2eaf0773d7d6@gmail.com>
- References: <CAM+dB2d4HcnH7PZRC4jYO8KLyNxs4pws_baT7WKi6vRiD2z1ow@mail.gmail.com><CAF_YUvURvhf+CkErvsCjNr=b=Nq2=FkM68Z_Tap3EsAzfArc+w@mail.gmail.com><da68f60e-dd23-8caa-7acd-2eaf0773d7d6@gmail.com>
I think Andrius's comments are relevant to the goal of 'high fidelity' conversion of CIFs. I've added some comments inline and some thoughts at the end.
--
On 20 April 2017 at 16:18, Andrius Merkys <andrius.merkys@gmail.com> wrote:
Dear all,
On 19/04/17 20:20, Robert Hanson wrote:
> Do you see these as having a serial array [...] at the top level or
> an associative array {....}?
I would recommend the use of a serial array [...] to preserve the order
of datablocks of input CIF. Some arguments for this approach:
1) Serial array removes the ambiguity of the datablock order in JSON ->
CIF conversion, thus different programs will by default produce
diff-able output;
Diffable output seems like a rather high bar to set and again, more suitable for a 'high fidelity' approach. Perhaps a similar effect could be obtained by sorting on datablock name and then dataname?
2) Input CIFs *may* contain two or more datablocks with the same name
(i.e. concatenated files, incorrect files), thus CIF -> JSON converters
with top-level object approach must have explicit guidelines which of
these datablocks will get overwritten or discarded;
Datablock names are arbitrary, and so the CIF input routine is free to choose different names or complain, as appropriate. Again, the approach in the draft is not a high fidelity approach but one that is consistent with CIF semantics.
3) I am aware of at least one CIF usage that makes use of datablock
order (Toby et al. 2003, https://doi.org/10.1107/S0021889803016819 ):
"The first block in the CIF contains information used in a publication";
I interpret this to mean that the CIF as output by GSAS2CIF will have publication information in the first datablock. This sentence does not have to be read as a requirement on input software to preserve this order, as the particular tags used for publication will be present only in this datablock, wherever it occurs. I accept that a 'high fidelity' approach will seek to preserve order, either in the expectation that it might be assigned semantic meaning at some point, or to preserve a layout that is helpful to a human reader.
4) One can always construct an associative array out of serial array,
whereas vice versa is ambiguous.
Indeed.
I understand that top-level object approach should be sufficient for the
most of use cases, but I would argue against the loss of order information.
Andrius's comments underline the different needs of CIF-JSON users, and I suggest that we should expect to have two variants.
I'd also like to offer a different perspective: that CIF JSON is an alternative instance of the ontology described in CIF dictionaries. That is, rather than see a CIF-JSON instance as always derived from a pre-existing CIF file, to instead view it as one of a variety of alternative containers for crystallographic information described by the CIF dictionaries (and HDF5 is another possibility). In this perspective, the requirements imposed by trying to capture the detailed CIF layout and syntax are irrelevant, and round-tripping is not a goal. Note that the CIF syntax files are still the preferred format for archival purposes.
If we adopt the above perspective, COD-JSON is a JSON that is always linked to a particular CIF file, and CIF-JSON is simply an alternative packaging of crystallographic information that may or may not be related to a file (e.g. it could simply be an interchange format internal to a set of scripts within a browser window). What do you think?
all the best,
James.
_______________________________________________
cif-developers mailing list
cif-developers@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/cif- developers
--
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
F +61 (02) 9717 3145
M +61 (04) 0249 4148
_______________________________________________ cif-developers mailing list cif-developers@iucr.org http://mailman.iucr.org/cgi-bin/mailman/listinfo/cif-developers
Reply to: [list | sender only]
- References:
- Draft JSON specification, round 2 (James Hester)
- Re: Draft JSON specification, round 2 (Robert Hanson)
- Re: Draft JSON specification, round 2 (Andrius Merkys)
- Prev by Date: Re: Treatment of Greek characters in CIF2
- Next by Date: Re: Treatment of Greek characters in CIF2
- Prev by thread: Re: Draft JSON specification, round 2
- Next by thread: RE: Draft JSON specification, round 2
- Index(es):