Exploring methods to index and search tree-structured key:value pairs via named-entity index (key paths) as opposed to Position-based indexing.

  • Using Rule as key->value causes difficulties for Cases, which is unfortunate since Rule could be combined with ReplaceAll to yield lightweight path queries.

  • Using List as {key,value} works but too many parentheses are visually confusing especially in data fusion tasks where multiple datasets are imported separately but must be joined and indexed properly for subsequent analysis.

  • Using Equal prevents the key from being a string, eg "key1" = value1 --> "Set::setraw : Cannot assign to raw object key1"

Why does Cases interpret Colon shortcut (key:value_) differently than Colon[key,value_]?

dataR (* for comparison *)

 Out[110]= {row1 -> {key1 -> value1, key2 -> value2}, 
 row2 -> {key1 -> value3, key2 -> value4}}

 In[69]:= dataC = dataR /. Rule -> Colon

 Out[69]= {row1 \[Colon] {key1 \[Colon] value1, key2 \[Colon] value2}, 
 row2 \[Colon] {key1 \[Colon] value3, key2 \[Colon] value4}}

Then, using Cases:

 In[113]:= Cases[dataC, Colon[row1  , v_] -> v]

 Out[113]= {{key1 \[Colon] value1, key2 \[Colon] value2}}

 In[114]:= Cases[dataC, (row1 : v_) -> v]

 Out[114]= {row1 \[Colon] {key1 \[Colon] value1, key2 \[Colon] value2},
  row2 \[Colon] {key1 \[Colon] value3, key2 \[Colon] value4}}

Levelspec can be specified to match the inner keys, eg key2 at Level 3.

Is there a more convenient syntax or method to rapidly restructure arbitrary tree-shaped data? XPath and XQuery, are W3C standards that could be adapted or improved. In particular, XQuery strikes me as being similar in flexibility as Cases in the ability to match and transform data. I've posed similar questions to Wolfram Tech Support. Has been suggested for implementation.

  • $\begingroup$ "I've posed similar questions to Wolfram Tech Support" Did you get any reply? $\endgroup$ – Ajasja Jul 16 '12 at 10:05

I'd like to discuss two points:

Cases, destructuring and escaping in patterns

There indeed can be a problem when using Cases to destructure expressions involving rules, because Cases has an extended syntax which uses rules, and interprets them differently. For example:

dataR = {row1 -> {key1 -> value1, key2 -> value2}, 
    row2 -> {key1 -> value3, key2 -> value4}}

Here is a naive attempt that will fail:

Cases[dataR, row1 -> _]

(* {} *)

This will work:

Cases[dataR, p : (row1 -> _)]

(* {row1 -> {key1 -> value1, key2 -> value2}} *)

The reason is that the colon (which is a short-cut for Pattern) serves as an escaping mechanism in this case. The "politically correct" way to perform escaping in patterns is however to use Verbatim:

Cases[dataR, Verbatim[Rule][row1, _]]

(* {row1 -> {key1 -> value1, key2 -> value2}} *)

In some cases, particularly when you only need to collect some parts of the expression involving rules, this may be unnecessary since the escaping will be naturally achieved by the destructuring rule. Example:

Cases[dataR, (row1 -> x_) :> x]

(* {{key1 -> value1, key2 -> value2}} *)

Better ways to destructure trees

You can use the fact that your tree is made of rules, to destructure it better. There were a few questions here about it, particularly this and this. Let me just show you a simple construct here:

destructure[tree_, keys__List] :=
   Fold[If[#2 === All, Flatten[#1[[All, 2]]], #2 /. #1] &, tree, keys]

This uses the fact that each branch is itself a set of rules. Some examples of use:


(* value1 *)


(* {value1,value2} *)


(* {value1,value2,value3,value4} *)
  • $\begingroup$ Thanks @LS. That's a great use of Fold. Is there a way to group values by level? That's the behavior of the ReplaceAll path query mechanism: {key2, key1} /. ({row2, row1} /. dataR) $\endgroup$ – alancalvitti Apr 4 '12 at 21:22
  • $\begingroup$ @alancalvitti Yes, you just do this: destructure[dataR, {{row2, row1}, {key2, key1}}] $\endgroup$ – Leonid Shifrin Apr 4 '12 at 21:51

The problem is that in the second case you used just the normal ASCII colon (the one you get by pressing :), which expands not to Colon but to Pattern. If you use the correct colon (Esc:Esc in the notebook, \[Colon] when typing directly into the kernel or writing a script), you also get the right result:

In[8]:= Cases[dataC, Colon[row1 , v_] -> v]

Out[8]= {{key1 : value1, key2 : value2}}

In[9]:= Cases[dataC, (row1 : v_) -> v]

Out[9]= {row1 : {key1 : value1, key2 : value2}, 

>    row2 : {key1 : value3, key2 : value4}}

In[10]:= Cases[dataC, (row1 \[Colon] v_) -> v]

Out[10]= {{key1 : value1, key2 : value2}}

The following demonstrates that the normal colon doesn't give Colon:

In[12]:= (row1 : v_)//FullForm

Out[12]//FullForm= Pattern[row1, Pattern[v, Blank[]]]
  • $\begingroup$ Good eye @celtschk. Well, who wants to type [Colon] every time, that removes the advantage over using List. Any other options? $\endgroup$ – alancalvitti Apr 4 '12 at 20:46
  • $\begingroup$ You might try to misuse NonCommutativeMultiply (**). However I'm not sure whether there are any built-in transformations which might become problematic here. $\endgroup$ – celtschk Apr 4 '12 at 21:08
  • $\begingroup$ A Docs link for the : operator, Pattern, may be useful. +1 $\endgroup$ – kglr Apr 4 '12 at 21:17
  • $\begingroup$ @kguler: I've now added documentation links for both Colon and Pattern. $\endgroup$ – celtschk Apr 4 '12 at 21:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.