Wesby 2.0 Lab Notebook

This document will act as a lab notebook for the development of Wesby.

---

2016/01/15

Happy new year! 🎆

Search in Wesby

Wesby will include a search engine that will retrieve resources based on text queries input by the user. In the first iteration the search engine will search the resources by its label. Some sort of ranking system will be needed to decide which resources are more relevant. A next step will be to search not only by label but also by resource type (rdf:type for example). Extending this functionality, Wesby could search resources by label and any kind of properties, not only its type. This basic search engine can be easily built translating GET requests to SPARQL queries. Something like the following:

http://example.org/data/search?q=query&qp=property&type=type

http://example.org/data/search?q=Bob&qp=foaf:name&type=foaf:Person 
SELECT ?label WHERE {
  ?q a foaf:Person .
  ?q foaf:name ?label
  FILTER regex(?label, "Bob", "i")
}

http://example.org/data/search?q=Bob&p=foaf:name&tp=dct:subject&to=dbc:Living_people
SELECT ?label WHERE {
  ?q dct:subject dbc:Living_people .
  ?q foaf:name ?label
  FILTER regex(?label, "Bob", "i")
}

Finally, it should implement a full text search engine. This could be achieved using a RDF index, using Apache Lucene or a similar technology.

2015/05/11

Notes about the templates

{{#with this}}
<h1>{{@graph.label}}</h1>
  <h2>Properties</h2>
  <table>
    <tr>
      <th>Property</th>
      <th>Value</th>
    <tr>
    {{#[@graph]}}
      {{#each this}}
        <tr>
          <td>{{[@context].xsd}}{{@key}}</td>
          <td>{{this}}</td>
        </tr>
      {{/each}}
    {{/[@graph]}}
  </table>
      {{[@context].xsd}}
{{/with}}

2015/31/07

Template matching in Wesby 2.0

In the previous version, Wesby matches each resource to its template using the rdf:type property. If this property doesn't exist, or there is no matching template, it applies the default template.

This system faces several problems: What happens when a resource has more than one type? We could select a random one, and maybe give the user the option to choose the most appropriate. What if this property is wrong? It may mess up the template, or apply the wrong one.

As of Wesby 2.0, we've come up with a better alternative:

Each template will have a corresponding SHACL shape, and Wesby will try to match the resources against them using ShExcala. This library will report which shape matches the resource, so we can just apply the corresponding template. What if the resource doesn't match any shape? It will just apply the default shape, just like the previous version. It may well be that the resource is supposed to be of a certain type but it has an error. In this case, it won't match any shape, but it won't fail rendering either.

Notes about ShExcala

####Matching: val schema = Schema.fromFile("path", "SHEXC") es.weso.shex.Matcher(schema, rdf)

shexcala --schema issue-simple.shex --endpoint http://example.org/ds/query --node http://example.org/Bob
shexcala -e http://example.org/ds/query -n http://example.org/issue1 -s issue-simple.shex -l http://example.org/IssueShape
shexcala --schema issues.shex --data issues.ttl

2015/23/07

In the past few days I added more serialising formats. Now I'm adding basic support for LDPC resources (containers).

2015/20/07

Wesby will try to comply, to the extent possible, with the LDP specification. To achieve this, I added the official W3C LDP test suite to the project and will gradually implement the different tests. My goal is not to make a perfect implementation of the LDP but I will try to stick to the standards.

2015/15/07

The query engine will have methods that query the SPARQL endpoint and return the results as Rdf#Solutions or Rdf#Graph. Later, this solutions will be rendered in the suitable format for the requested MIME type. Today, I added a plain text renderer and modified the select queries.

2015/14/07

I added an early prototype of text/plain dereferencing.

2015/07/07

Reminder on running the Fuseki test server

cd fuseki
fuseki-server --update --loc=ds /ds

2015/07/07

I'm evaluating if Wesby should implement the Linked Data Platform. It makes sense since Wesby works on RDF resources (it always retrieves the HTML representation of an RDF resource). Furthermore, one of the goals for version 2.0 is the ability to edit this resources from within the browser. This could be achieved using using HTTP methods like the LDP specification describes.

2015/07/06

I created a docs branch for Read The Docs documentation.

2015/05/06

Travis is working again. I added a simple QueryEngine to test Banana-RDF. It's working.

2015/04/06 I18n and dereferencing

The new system will have i18n, so I created a few messages files and set up i18n in the project. It is working fine. I also rethought the URI dereferencing strategy followed in 1.0. The old system used URIs did dereferencing like this:

http://example.org/resource/subject --303-->

http://example.org/resource/subject?format=html

The new system will do it like this:

http://example.org/resource/subject --303-->

http://example.org/resource/subject.html

The rationale behind this is based in the Cool URIs guidelines described here.

Tasks done:

• Add i18n
• Add routes for the new dereferencing

Problems:

Turns out Travis is not working...

2015/03/06 Fresh start

In the next months I will rewrite Wesby from scratch.

The new system will be written in Play Framework 2.4.0, with Banana-RDF.

Tasks done:

• Cean up of the old repository (old branches etc.)
• New 2.0 branch.
• Project created.
• Add Travis.