prefixes (unstable) as JSON Object

[ch-sander]

prefixes (unstable) at https://docs.sparnatural.eu/Javascript-integration.html#html-attributes-reference

I imagine the space after the colon is just a typo (or doesn't matter) in the example: foaf: http://xmlns.com/foaf/0.1/ skos:http://www.w3.org/2004/02/skos/core#

However, I was wondering what is unstable here and if it was possible to pass a JSON object, e.g. @ context like in JSON-LD, instead of this string. Would make integration more robust.

[tfrancart]

I imagine the space after the colon is just a typo (or doesn't matter)

shouldn't matter

However, I was wondering what is unstable here

This is less and less unstable. It triggers additionnal reparsing of the SPARQL query strings (final one and the ones in the list / autocomplete)

it was possible to pass a JSON object

No. Passing JSON objects inside HTML attributes is ugly. RDFa prefix syntax is identical: https://www.w3.org/TR/rdfa-core/#examples

[ch-sander]

Why isn't the query bound to prefixes with such config

<spar-natural 
            src="/static/sparnatural/config.ttl"           
            endpoint="https://g17dev.dhi-roma.it/sparql"
            lang="en"
            defaultLang="en"
            distinct="true"
            limit="10000"
            debug="true"
            prefixes="grace:http://www.graceful17.org/ontology/ g17:http://www.graceful17.org/resources/ "
        ></spar-natural>

The sparql will still be rendered like

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
SELECT DISTINCT ?archive_1 ?archive_1_label ?GIS_2 ?GIS_2_label WHERE {
  ?archive_1 rdf:type <http://www.graceful17.org/ontology/archive>;
    <http://www.graceful17.org/ontology/called> ?archive_1_label;
    <http://www.graceful17.org/ontology/wkt> ?GIS_2.
}
LIMIT 10000

I must be missing something here...sorry!

[tfrancart]

Probably because you have https in your prefixes but http in your query :-)

[ch-sander]

At the risk of embarrassing myself even more: I don't see https (only in the query endpoint but this cannot be it).

[ch-sander]

@tfrancart sorry to be in your neck with this, but you have any idea why it won't work (#637 and #587)?