Thanks Holger

that workaround did the trick!


On Tuesday, 22 December 2020 at 11:28:38 UTC+11 Holger Knublauch wrote:

> 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
>
>
> On 2020-12-22 10:08 am, [email protected] wrote:
>
> 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?
> On Thursday, 17 December 2020 at 15:13:05 UTC+11 Holger Knublauch wrote:
>
>> 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
>>
>>
>> On 2020-12-17 12:50 pm, [email protected] wrote:
>>
>>
>> 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> 
>> <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
>>
>> -- 
>> 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 [email protected].
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/topbraid-users/4a6b9e7b-b4d6-4fed-88ac-c710aea054c9n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/topbraid-users/4a6b9e7b-b4d6-4fed-88ac-c710aea054c9n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> -- 
> 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 [email protected].
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/topbraid-users/31f90fce-912b-4099-8a7d-63a3321d928en%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/topbraid-users/31f90fce-912b-4099-8a7d-63a3321d928en%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/e055ccb3-765e-47b8-8f93-b6564acfcb93n%40googlegroups.com.

Reply via email to