ValueTableViewer picking up properties from other shapes

[robatki...@gmail.com]

I have a ValueTableView for a class which works fine and displays the properties i want, using a sh:node according to the documentation at:

http://datashapes.org/forms.html#ValueTableViewer

when an instance of the class is also a skos:Concept, and I include the skos shapes 

owl:imports <http://topbraid.org/skos.shapes> ;  then the table view adds empty rows for all the possible skos properties, even though the SKOS shapes doesnt bind skosk:Concept to a  sh:node ...

I can't avoid having the import (easily) because its a taxonomy asset class - the purpose of my class declaration is to have class-specific views at different levels in the taxonomy..

so three questions:

1) is this a bug?

2) if not, what is the actual mechanism it uses, and is it documented? 

3) regardless, how can I suppress this behaviour?

Cheers

Rob

[Holger Knublauch]

Hi Rob,

the original intent of this dash:ValueTableViewer is to render custom tables, where a dedicated sh:NodeShape is defined for the columns. Just like in the online example sh:node should be used to link the sh:PropertyShape with that node shape.

It is also a read-only table, which means that a typical use case is to use it for inferred values.

I do notice however that currently, in the absence of a sh:node constraint it will fall back to using the sh:class, which in your case is probably a subclass of skos:Concept. I need to review this for 7.0.

On the short term, try defining a dedicated sh:NodeShape just for that table, using sh:node. Only those columns should appear if you do that.

If you're getting stuck, please provide snippets/details of what you have attempted so far.

Holger

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/4a6b9e7b-b4d6-4fed-88ac-c710aea054c9n%40googlegroups.com.

[robatki...@gmail.com]

I  have this..

ra:RaClass

  rfds:subClassOf skos:Concept ;  #(defined in an imported graph) 

  rdf:type sh:NodeShape ;

  sh:property ra:RaClass-hasClusion ;

ra:RaClass-hasClusion

  rdf:type sh:PropertyShape ;

  sh:path ra:hasClusion ;

  dash:viewer dash:ValueTableViewer ;

  sh:class ra:Clusion ;

  sh:node ra:clusionTable ;

.

And it picks up the columns defined in ra:clusionTable - the problem is that is also picks up the properties for skos:Concept making the table unusable ;-(

is there a SPARQL query we could run to determine what it picks up? Could we force a deactivation on these SKOS shapes for this case somehow?

[Holger Knublauch]

Right, in the current version you'd need to remove the sh:class constraint so that it really only uses the sh:node shape. For 7.0 this has been changed so that sh:node will always be preferred if both art present.

If you cannot remove the sh:class constraint, I recommend defining a new property that infers its values and only has a sh:node constraint, e.g. (untested):

ra:RaClass-hasClusion-view

  rdf:type sh:PropertyShape ;

  sh:path ra:hasClusionView ;

  dash:viewer dash:ValueTableViewer ;

  sh:values [ sh:path rs:hasClusion ] ;

  sh:node ra:clusionTable ;

.

Keep in mind that dash:ValueTableViewer is read-only, so you may want to apply it on an inferred property anyway. You could mark the other property dash:hidden true instead.

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/31f90fce-912b-4099-8a7d-63a3321d928en%40googlegroups.com.

[robatki...@gmail.com]

Thanks Holger

that workaround did the trick!