| 15 | ! needs queryModel - Values |
| 16 | |
| 17 | profile overview:: |
| 18 | important starting question: which profiles are actually used: |
| 19 | {{{ |
| 20 | ?operation=queryModel&q=//CMD/Components |
| 21 | }}} |
| 22 | however this returns only the root elements, which may not unambiguously refer to the profiles.[[BR]] |
| 23 | `CMD/Header/MdProfile` should refer to the correct profile, but may not be always filled. (+ requires queryModel to return Values!) |
| 24 | {{{ |
| 25 | ?operation=queryModel&q=//MdProfile |
| 26 | ?operation=queryModel&q=//CMD/Components/MdProfile |
| 27 | }}} |
| 44 | xpath: //IsPartOf[.='test-hdl:1839/00-0000-0000-0001-494F-5'] |
| 45 | //IsPartOf[.='clarin-at:aac-test-corpus:sozialismus'] |
| 46 | }}} |
| 47 | So to get the whole collection (all resources of the collection) we use `operation=searchRetrieve` and query element `IsPartOf`:[[BR]] |
| 48 | [http://demo.spraakdata.gu.se/clarin/cmd/model/stats?operation=searchRetrieve&query=//IsPartOf%5B.=%27clarin-at:aac-test-corpus:sozialismus%27%5D collection(clarin-at:aac-test-corpus:sozialismus) ] |
| 49 | |
| 50 | As the `IsPartOf`-relation is fully expanded (every resource references via `IsPartOf` every ancestor-collection CMD-record, not just the parent), the simple quey as introduced above returns all descendants, not only children, which should actually be the default behaviour. One possible resolution would be to add an attribute `@ancestor-level` or similar, which would allow to distinguish the depth of the `IsPartOf`-relation. Querying just the children would be accomplished by: |
| 51 | {{{ |
| 52 | //IsPartOf[@ancestor-level=1][.='clarin-at:aac-test-corpus:sozialismus'] |
| 53 | }}} |
| 54 | This would even allow for flexible maximum depth of the query wrt to the collection-hierarchy. |
| 55 | |
| 56 | Querying multiple collections translates to a `OR`-query: |
| 57 | {{{ |
| 58 | xpath: //IsPartOf[.='{handle-coll1}' or .='{handle-coll2}'] |
| 59 | //IsPartOf[@ancestor-level=1][.='{handle-coll1}' or .='{handle-coll2}'] |
| 60 | }}} |
| 84 | Boolean CQL-queries are easily conversible into XPath, they just have to be contextualised with some same ancestor node, like this: |
| 85 | {{{ |
| 86 | //Session[contains(Date,'2005')][contains(.//Description,'participant')] |
| 87 | }}} |
| 88 | Currently it may not be the root node `CMD` itself, because MDRepository searches for the `ancestor::CMD` of the XPath |
| 89 | So this will result in 0 (irrespective of the actual conditions) |
| 90 | {{{ |
| 91 | ! //CMD[contains(.//Title,'year')][.//Date='2001-11-21'] |
| 92 | }}} |
| 93 | But this would work: |
| 94 | {{{ |
| 95 | //CMD/Components[contains(.//Title,'year')][.//Date='2001-11-21'] |
| 96 | //CMD/*[contains(.//Title,'year')][.//Date='2001-11-21'] |
| 97 | //Components[contains(.//Title,'year')][.//Date='2001-11-21'] |
| 98 | }}} |
| 99 | Usually using `Components` as starting point is best, if searching in the actual metadata. This however does not cover the `/CMD/Header` and `/CMD/Resources` part of the MD-records. This is especially the case when constraining the collections with `IsPartOf`: |
| 100 | {{{ |
| 101 | //CMD/*[contains(.//Title,'year')][.//Date='2001-11-21'][.//IsPartOf='{handle-coll1}'] |
| 102 | (: this wouldn't work: :) |
| 103 | ! //CMD/Components[contains(.//Title,'year')][.//Date='2001-11-21'][.//IsPartOf='{handle-coll1}'] |
| 104 | }}} |