coordinate1, coordinate2, coordinate3 -> coordinate

[cmaumet]

As we are already using json arrays in a number of cases including:

• the contrast vector (e.g. prov:value "[1, 0, 0]")
• the voxel units (e.g. nidm:voxelUnits "['mm', 'mm', 'mm']")
• the voxel size (e.g. nidm:voxelSize "[3, 3, 3]")
• ...

For consistency, could we also use a json array to describe coordinates (instead of having coordinate1, coordinate2, coordinate3...)? This update would be as follows:

niiri:coordinate_0001_1 a prov:Entity , prov:Location , nidm:Coordinate ;
    rdfs:label "Coordinate 0001_1" ;
    nidm:coordinate "[-8.35, 15.1, 39.6]"^^xsd:string ;
    fsl:coordinateInVoxels "[33, 38, 31]"^^xsd:string .

instead of:

niiri:coordinate_0001_1 a prov:Entity , prov:Location , nidm:Coordinate ;
    rdfs:label "Coordinate 0001_1" ;
    nidm:coordinate1 "-8.35"^^xsd:float ;
    nidm:coordinate2 "15.1"^^xsd:float ;
    nidm:coordinate3 "39.6"^^xsd:float ;
    fsl:coordinate1InVoxels "33"^^xsd:float ;
    fsl:coordinate2InVoxels "38"^^xsd:float ;
    fsl:coordinate3InVoxels "31"^^xsd:float .

Please let me how you feel about this. Thank you!

[nicholsn]

I prefer the array syntax too, but it does mean you need to parse the json string to access each element, while the predicate-wise listing allows access to specific coordinates in a query. For example, I think you could query for all coordinates in some bounding box.

Another approach worth considering, might be to move towards ordered lists in RDF/JSON-LD. For example, in json-ld you can use the @list keyword to define an ordered list:

{
  "@context": "http://schema.org/",
  "@type": "Person",
  "jobTitle": "Professor",
  "name": {
    "@list": [
      "joe",
      "bob",
      "jaybee"
    ]
  },
  "telephone": "(425) 123-4567",
  "url": "http://www.janedoe.com"
}

And similarly in turtle using parentheses ( item1, item2, itemN):

[]
    <http://schema.org/jobTitle> "Professor" ;
    <http://schema.org/name> ("joe"
        "bob"
        "jaybee"
    ) ;
    <http://schema.org/telephone> "(425) 123-4567" ;
    <http://schema.org/url> <http://www.janedoe.com> ;
    a <http://schema.org/Person> .

The rub is that I don't think PROV-N supports ordered lists like this, which is why I think we went with quoted json arrays as strings in the first place. Makes me question what the real utility of PROV-N really is at this point.

[cmaumet]

We discussed this issue on NIDASH call on March 23rd (Minutes):

• we agreed on using json arrays (as the separate attributes can be easily re-generated if needed).
• @satra will look at whether there is a better type to use than xsd:string to explicitly state that the value is a json-array.

[cmaumet]

Now implemented and ready to merge. Issue #297 is open to discuss typing to be used for json-array.