Add support for editing labels and value comments

[tobiasschweizer]

This adds:

• Support for viewing and editing resource labels in SALSAH.
• Support for querying, editing, and deleting value comments.
• Support for property predicate inheritance in the ontology responder, which was missing from Redesign the ontology responder for better performance #252.
• The ability for a resource class to be a subclass of something that isn't a resource class, e.g. foaf:Person.
• The ability for a Knora resource property to be a subproperty of something that isn't a resource property, e.g. foaf:name.
• GUI support for knora-base:UriValue and knora-base:BooleanValue.
• Sorting property definitions by guiorder in the API response describing a resource type, so they're sorted that way in the form for creating a new resource.

It also fixes these GUI bugs:

• When creating a new resource, if you clicked on the red X buttons to remove optional properties, invalid JSON was submitted.
• It was possible to select knora-base:Region as the type of resource to be created, but this didn't make sense.
• There was a button for adding a value for the property knora-base:hasStandoffLinkto, but users shouldn't be able to do that.

Closes #271.
Closes #263.

[tobiasschweizer]

This is it, I have to add the named graph to the update query:

WITH <http://www.knora.org/data/incunabula>
DELETE ...

I can get the resource's project from the resinfo query and find out the named graph like this

[tobiasschweizer]

I wanted to use this in the update query's where clause:

?resource rdf:type ?resourceClass ;
            knora-base:isDeleted false .
    ?resourceClass rdfs:subClassOf+ knora-base:Resource .

But with the statement ?resourceClass rdfs:subClassOf+ knora-base:Resource ., the update takes no effect in fuseki.

[benjamingeer]

That's correct. The DELETE and INSERT clauses have to specify the named graph, or you can use WITH, which covers the whole update. You can look at some of the other update queries for examples.

[benjamingeer]

The second problem is because you're using WITH. The class knora-base:Resource isn't defined in the Incunabula named graph, so your WHERE clause can't see it. Instead of using WITH, specify the named graph using GRAPH in the DELETE and WHERE clauses.

[benjamingeer]

While you're at it, you could make the same change to changeComment.scala.txt, which doesn't check the resource class and uses WITH.

[tobiasschweizer]

Actually I have just removed the resource class check from the where clause in the update (the check is included in resinfo and later in the label update check) since it requires two named graphs: the one the resource is in and knora-base.

Or could I specify the named graph only in the DELETE and INSERT using GRAPH?

specify the named graph using GRAPH in the DELETE and WHERE clauses

Did you mean INSERT instead of WHERE?

If so, I can adapt the label update as well as the comment later today.

[benjamingeer]

Yes, sorry, I meant INSERT instead of WHERE. Look at how it's done in the other update queries. They all say DELETE { GRAPH <...> { ... } } INSERT { GRAPH <...> { ... } } WHERE { ... }. Only the DELETE and INSERT clauses have GRAPH, not the WHERE clause.

[tobiasschweizer]

fdfd984

I also checked that resource is not marked as deleted in changeComment.scala.txt. I assume that only values of resources that are not marked as deleted can be changed.

By the way: If I remember correctly we do not mark values as deleted when you mark the resource as deleted. So we should check the resource's deletion state whenever an update is requested for a value. Right or am I mistaken?

[benjamingeer]

By the way: If I remember correctly we do not mark values as deleted when you mark the resource as deleted. So we should check the resource's deletion state whenever an update is requested for a value. Right or am I mistaken?

You're right. We do check, except in changeFileValueV1. I've assigned the issue to you: #272. :)

[benjamingeer]

This is ready to review, @tobiasschweizer can you have a look?

[tobiasschweizer]

with great pleasure, but tomorrow

[benjamingeer]

We couldn't figure out how to get the label to display on a region. So far we traced the problem to this code at the end of jquery.propedit.js:

        var prop_index = 0;
        return this.each(function() {
            var prop = $(this).data('propname');
            // console.log(prop);
            reset_field(prop, prop_index, options.readonly);
            prop_index++;
        });

Here prop is never __label__, but we couldn't figure out why. It seems that $(this).data is constructed differently for a page and for a region, but we don't see how.

[benjamingeer]

We are fixing some comment editing bugs on this branch.

The main remaining problem is that when you edit a comment, the GUI doesn't reset the value with the IRI of the new value version. This needs to be fixed in jquery.propedit.js (see the comment on line 139) and in jquery.valcomment.js.

[tobiasschweizer]

Next week, we should adapt the browser tests so they pass.

The problem was that we hadn't any sorting of the properties in the GUI so far (GUI order). Now, as long as they GUI order is not changed, this should behave in a consistent manner.