You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<li><ahref="https://github.com/reconciliation-api/specs/pull/149">Move the <code>query</code> field of reconciliation queries inside <code>properties</code> to allow for queries which do not provide entity names</a></li>
251
251
<li><ahref="https://github.com/reconciliation-api/specs/pull/156">Add optional <code>standardizedScore</code> field to the manifest</a></li>
252
252
<li><ahref="https://github.com/reconciliation-api/specs/pull/166">Unify naming to camelCase convention</a></li>
253
+
<li><ahref="https://github.com/reconciliation-api/specs/pull/193">Add <code>limit</code> parameter to suggest queries and rename <code>cursor</code> to <code>offset</code></a></li>
253
254
</ul>
254
255
</section>
255
256
</section>
@@ -549,19 +550,19 @@ <h3>Structure of a Reconciliation Query</h3>
549
550
<dl>
550
551
<dt><code>matchType</code></dt>
551
552
<dd>Either <code>name</code> or <code>property</code>, depending on whether the condition relates to entity names or their properties.</dd>
552
-
<dt><code>pid</code></dt>
553
+
<dt><code>propertyId</code></dt>
553
554
<dd>A <ahref='#properties'>property</a> identifier, to be provided if and only if the <code>matchType</code> is <code>property</code>.</dd>
554
-
<dt><code>v</code></dt>
555
+
<dt><code>propertyValue</code></dt>
555
556
<dd>one or more <a>property values</a>. If <code>matchType</code> is <code>name</code>, then this value is to
556
-
be matched to entity names, otherwise to the property values via the supplied <code>pid</code>. The specifics of how this similarity
557
+
be matched to entity names, otherwise to the property values via the supplied <code>propertyId</code>. The specifics of how this similarity
557
558
is defined are determined by the service.</dd>
558
559
<dt><code>required</code></dt>
559
560
<dd>An optional boolean indicating if a match for the property is required for an entity to enter the list of candidates (i.e. acting like a filter or a WHERE clause in SQL)
560
561
or optional (i.e. only effecting the entity's rank in the list of candidates). If omitted, the service SHOULD assume the requested value to be <code>false</code>;</dd>
561
562
<dt><code>matchQuantifier</code></dt>
562
-
<dd>An optional string to indicate which of the values in <code>v</code> to match. MUST be <code>any</code> (equivalent to boolean OR), <code>all</code> (equivalent to boolean AND), or <code>none</code> (equivalent to boolean NOT). If omitted, the service SHOULD assume the requested value to be <code>any</code>;</dd>
563
+
<dd>An optional string to indicate which of the values in <code>propertyValue</code> to match. MUST be <code>any</code> (equivalent to boolean OR), <code>all</code> (equivalent to boolean AND), or <code>none</code> (equivalent to boolean NOT). If omitted, the service SHOULD assume the requested value to be <code>any</code>;</dd>
563
564
<dt><code>matchQualifier</code></dt>
564
-
<dd>An optional string to indicate how to match the values in <code>v</code>.
565
+
<dd>An optional string to indicate how to match the values in <code>propertyValue</code>.
565
566
This can be used for general matching relations like "skos:exactMatch", "skos:closeMatch", etc. or for specific features like spatial matching with geo data
566
567
(e.g. containment search with "schema:containsPlace" etc.) or custom matching on date fields (e.g. services supporting the [[EDTF]] specification could use "EDTF:Level-0" etc.
567
568
To allow discovery of supported qualifiers by clients, services that support <code>matchQualifier</code> MUST return the supported <code>matchQualifiers</code> for each property
@@ -778,10 +779,15 @@ <h3>Suggest Queries</h3>
778
779
<dd>The string input by the user in the auto-suggest-enabled field;
779
780
depending on the data users are working with, they might want to select a suggestion from all available <a>types</a>, <a>properties</a>, or even <a>entities</a>;
780
781
to allow that, services MAY send all suggestions if the prefix is empty, and clients SHOULD provide a way to send the empty prefix;</dd>
781
-
<dt><code>cursor</code></dt>
782
+
<dt><code>limit</code></dt>
783
+
<dd>An optional integer to specify the number of suggestions to return.</dd>
784
+
<dt><code>offset</code></dt>
782
785
<dd>An optional integer to specify the number of suggestions to skip: this can be used by clients to fetch more suggestions.</dd>
<p>All objects used in this protocol (entities, types, properties, queries, candidates, features, etc.) MAY declare an explicit <a>text-processing language</a> in a <code>lang</code> field.
1003
1009
The <code>lang</code> value MUST be a single valid (i.e. found in the [[IANA Language Subtag Registry]]) [[BCP 47]] language tag. This text-processing language applies to the natural language fields of the object: <code>name</code>, <code>description</code>,
1004
-
<code>query</code> (for <a>reconciliation queries</a>), <code>v</code> and <code>str</code> (for <a>property values</a>), <code>helpText</code> (for <a>data extension property settings</a>). Nested objects inherit the text-processing language of their parent, and can override it by setting their own <code>lang</code> value
1010
+
<code>query</code> (for <a>reconciliation queries</a>), <code>propertyValue</code> and <code>str</code> (for <a>property values</a>), <code>helpText</code> (for <a>data extension property settings</a>). Nested objects inherit the text-processing language of their parent, and can override it by setting their own <code>lang</code> value
1005
1011
(see example below). A default text-processing language for any natural language string returned or processed by a service MAY be set in the <code>lang</code> field of the <ahref="#service-manifest">service manifest</a>.
1006
1012
Client and service implementors SHOULD consider the text-processing language to ensure correct processing of natural language content.</p>
1007
1013
@@ -1017,7 +1023,7 @@ <h3>Text direction</h3>
1017
1023
1018
1024
<p>All objects returned by reconciliation services (entities, types, properties, candidates, features, etc.) MAY declare an explicit text <ahref="https://www.w3.org/International/articles/inline-bidi-markup/uba-basics">
1019
1025
base direction</a> in a <code>dir</code> field. The <code>dir</code> value MUST be <code>ltr</code> for left-to-right, <code>rtl</code> for right-to-left, or <code>auto</code> for determining the direction by examining the content of each JSON field.
1020
-
This base direction applies to the natural language fields of the object: <code>name</code> and <code>description</code> (for candidates etc.), <code>v</code> and <code>str</code> (for <a>property values</a>), <code>helpText</code> (for <a>data extension property settings</a>).
1026
+
This base direction applies to the natural language fields of the object: <code>name</code> and <code>description</code> (for candidates etc.), <code>propertyValue</code> and <code>str</code> (for <a>property values</a>), <code>helpText</code> (for <a>data extension property settings</a>).
1021
1027
Nested objects inherit the base direction of their parent, and can override it by setting their own <code>dir</code> value. A default base direction for any natural language string returned or processed by a service MAY be set in the <code>dir</code> field of the
1022
1028
<ahref="#service-manifest">service manifest</a>. If no explicit base direction is given, left-to-right is considered the default base direction. Clients SHOULD consider the base direction to ensure correct rendering of content, e.g. by setting corresponding <code>dir</code> attributes when rendering JSON responses in HTML.
1023
1029
For instance, rendering a Persian label for 'Yahoo!' like <code>یاهو!</code> right-to-left will correctly display as <codedir="rtl">یاهو!</code>.</p>
0 commit comments