filter to transform:

https://raw.github.com/timrdf/csv2rdf4lod-automation/master/doc/examples/source/lebot/golfers/version/original/manual/golfers.xls.zip

into:

https://raw.github.com...golfers.xls.zip ?

the "resource representation" returned should be equivalent in content regardless of format. So demanding new queries for each content-type is redundant and makes it too easy to violate AWWW by providing different content for the same URI request.

Hello,

I just installed lodspeakr out of the box using the simple install and noticed that every static component has the contents of settings.inc.php prepended to it. Viewing the source of the index.html and jquery files confirms this. I think even the lodspeakr_logotype.png file gets it prepended because firebug shows that it is corrupted.

Is there some configuration issue?

Thanks,

Gerald

Is it possible to deploy two lodspeakrs next to each other?

http://aquarius.tw.rpi.edu/prov-wg-dev/ results in

[Mon Mar 12 14:53:51 2012] [error] [client 128....] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.

aquarius:/var/www/prov-wg-dev

while http://aquarius.tw.rpi.edu/prov-wg/index.html works.

same for properties

for one of our schemas we have things like:

http://toolmatch.esipfed.org/schema#DataServer

If I go to the lodspeakr index page it's #tool:DataServer (namespace is tool)

Just wondering if user browses to http://toolmatch.esipfed.org/schema#DataServer it'll take you to the #DataServer anchor in lodspeakr.

I tried to set a default namespace, but that didn't work.

I spend a lot of time looking for prefixes, finding that there a query is missing a prefix, etc. LODSPeaKr should add the needed prefixes automatically.

https://github.com/timrdf/prov-lodspeakr/blob/c68030a729c50cee5b4f069400f9bdd2b102216c/components/services/prov-o/html.template

is including a local copy of http://dvcs.w3.org/hg/prov/raw-file/tip/examples/eg-9-provrdf-owl-coverage/rdf/create/rdf/eg-9-provrdf-owl-coverage.html.ttl via line 243:

        <div class="anexample">
        <div><b>Example</b></div>
           <p> Example of instances of class Entity from the <a href="http://www.w3.org/TR/2011/WD-prov-dm-20111018/#a-file-scenario"> provenance scenario </a> are files with identifiers <i>e1</i> and <i>e2
</i>. The RDF/XML syntax for asserting that e1 is an instance of Entity is given below.
           <div class="exampleOuter">
            <pre class="example">{% include "eg-9-provrdf-owl-coverage.html.ttl" %}</pre>
           </div>
        </div>

the example that is being included has angles, which need to be escaped:

@prefix dcat: <http://www.w3.org/ns/dcat#> .

http://aquarius.tw.rpi.edu/prov-wg/prov-o#simple-relationships-in-prov-o only shows:

@prefix dcat:  .
@prefix dcterms:  .
@prefix prov:  .
@prefix rdf:  .
@prefix rdfs:  .
@prefix xhv:  .
@prefix xml:  .
@prefix xsd:  .

models/service.configure-epoch/html.queries/biordf/local/previous_faqt_service_inputs.query contains select distinct ?input

and is named according to the pattern:

models.service.<service-name>/[<content-type>.]queries/<endpoint-name>/<endpoint-name>/<model-name>.query

views/service.configure-epoch/html.template contains

            {%for row in models.biordf.local.previous_faqt_service_inputs%}
               <option value='{{row.input.value}}'>{{row.input.value}}</option>
            {%endfor%}

(diagram at https://github.com/timrdf/DataFAQs/wiki/LODSPeaKr)

Problem: "models" and "views" feel too disconnected.

I'd suggest reorganizing the directory structure (again) to:

(defaults to local endpoint)
module/services/configure-epoch/queries/previous_faqt_service_inputs.query

(uses the local endpoint)
module/services/configure-epoch/queries/local/previous_faqt_service_inputs.query

(uses a non-default endpoint)
module/services/configure-epoch/queries/biordf/previous_faqt_service_inputs.query

(single, explicit endpoint)
module/services/configure-epoch/queries/biordf/endpoint.local/previous_faqt_service_inputs.query 

(cross-format, cascading queries)
module/services/configure-epoch/queries/endpoint.biordf/endpoint.local/previous_faqt_service_inputs.query

(format-specific cascading queries)
module/services/configure-epoch/queries/html/endpoint.biordf/endpoint.local/previous_faqt_service_inputs.query

module/services/configure-epoch/html.template
module/services/configure-epoch/json.template

This way, everything I need to create a service is in a single directory. Also, the scoping of the hierarchy is nice. The template is "higher" than all of the queries, which would be completed at the lower end of the tree.

No need to group templates in to a separate directory, let them be evident directly within the service directory, since that IS what is shown by the service.

When referencing the models within the template (e.g. {%for row in models.biordf.local.previous_faqt_service_inputs%}), this path matches the relative path in the directory structure (though, "queries" in my proposal would be renaming "models" which I'm okay with b/c the model is the entire structure of the 'queryies' directory structure.).

use case:

prefix prov:   <http://www.w3.org/ns/prov-o/>
prefix select: <http://sparql.tw.rpi.edu/services/datafaqs/core/select-faqts/> 

select distinct ?input
where {
  []
     prov:wasAttributedTo {{base.args.arg0}};
     prov:used            ?input;
  .
}

where the param is some unknown URI (so it is a hassle to find a qname for it.)

In https://github.com/alangrafu/lodspeakr/wiki/Special-URIs you show code example:

{%for h in base.header %}

perhaps it would be easier to use if it were something like:

{%for h in lodspeakr.header %}

much like how jquery is the (long-named) object you use to use jquery. It would help developers know when they are talking to lodspeakr and when they are talking to, say haanga or something.

or something shorter like lodspk so it is easier to type.

In a template, models.get provides a direct way to reference the result bindings, but some maintenance is needed to provide a link to the query file used (which is encoded in PROV RDFa in this example).

      {% for row in models.get %}
         <tr>
...
         </tr>
       {% endfor %}
...
      <p about="#results">
      <a rel="prov:used" href="{{lodspk.baseUrl}}prov-lodspeakr/components/services/retrievals/queries/get.query"/>query</a>
      </p>

Example: Serving data from namespace http://lofd.tw.rpi.edu/ in http://lofd.tw.rpi.edu/~lebot/. Installing lodspk in ~lebot/ won't turn the mirroring option on

Hi Alvaro,

Could you allow to add a 4th variable to the GoogleMaps visualisation?

GoogleMaps:"lat,long,conflict,radius";

This would display circles of various radiuses on the google map.

Add

OPTIONAL { ?o rdfs:label ?label }

and

{%if row.label.value%}{{row.label.value}}{%else%}{{row.o.value}}{%endif%}

in templates

to queries (in types/rdfs:Resource, service/instances, etc.)

The lack of a controller component was an intentional in the first versions of lodspk. However more and more I see the need of it for other functions besides data publishing:

• You want to add data form other sources
• You want to manage data using other libraries (e.g., statistical libraries) that are beyond of what lodspk and Haanga can/want to do
• You want to enable read/write operations
• You want to control which queries will be executed depending on previous results
  • Corolary: change the endpoint of a query?
• You want to list all the services, types and uri components available in a lodspk installation without doing a hack :)

For all this, we need to specify:

• If no controller exists, keep things as usual (execute queries, apply results in template)
• If controller is available, support:
  • HTTP PUT, DELETE and POST at least
  • Flow control
  • Api for accessing SPARQL endpoint?
  • Others

main and queries do not align between the query file path and how it is called in the template. Aligning these would make it easier to understand and remember.

lebot@aquarius:/var/www/prov-wg/prov-lodspeakr/components/services/provrdf-owl-coverage$ grep "select" queries/main.query 
select distinct ?construct ?yes


lebot@aquarius:/var/www/prov-wg/prov-lodspeakr/components/services/provrdf-owl-coverage$ grep "row in" html.template 
      <ul> {% for row in models.main %}