Re: [topbraid-users] Small label error to fix

[Ralph Hodgson]

Thanks - will fix 

Sent from my iPhone

> On Apr 8, 2021, at 12:06 PM, Tim Smith  wrote:
> 
> 
> Hi,
> 
> I noticed that the two classes, edg:DerivationMapLink and 
> edg:DerivationMapNode share the same label "Derivation Map Node", making the 
> Derivation Map Node appear twice in the class hierarchy.
> 
> Thanks,
> 
> Tim
> 
> 
> 
> 
> 
> -- 
> 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-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/topbraid-users/CAF0WbnJFd38MWBnTq-0__nqUW0JXud9xz-PVmah_1FQ-zKoUmA%40mail.gmail.com.

-- 
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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/8ACC285D-A5DB-4639-A40F-E64127FB1535%40topquadrant.com.

[topbraid-users] Small label error to fix

[Tim Smith]

Hi,

I noticed that the two classes, edg:DerivationMapLink and
edg:DerivationMapNode share the same label "Derivation Map Node", making
the Derivation Map Node appear twice in the class hierarchy.

Thanks,

Tim

[image: image.png]
[image: image.png]

-- 
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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAF0WbnJFd38MWBnTq-0__nqUW0JXud9xz-PVmah_1FQ-zKoUmA%40mail.gmail.com.

[topbraid-users] Shape hierarchy

[Tomasz Pluskiewicz]

Hi

I'm trying to figure out the best way to validate requests using SHACL 
where the shapes from a hierarchy, defined as rdfs:Class + rdfs:subClassOf 
and each shape has an implicit target.

# shapes graph
 a rdfs:Class, sh:NodeShape ;
  rdfs:subClassOf  .

 a rdfs:Class, sh:NodeShape .

# data graph
<> a  .

I saw this comment 
 and 
it makes most sense with a data graph possibly retrieved from a store with 
reasoning enabled. That would provide a full information derived from the 
subclass statements.

However, in my HTTP request scenario, I only get the explicit rdf:type 
triple and for practical reasons want to avoid using a reasoner in the API 
code. Thus, only the  shape's constraints will apply. It would be 
similar in a web UI.

The shapes graph and data graph are separate and I'd like it to stay that 
way.

I'm looking at two ways for approaching this:

1. Copy all rdfs:subClassOf statements into the data graph for the sole 
purpose of running the validation.
2. Gather the super classes for every shape and add them as `sh:and` lists 
to the sub classes.

I'm leaning towards the latter, where the result would add the following to 
the shapes graph

 sh:ad (  ) .

Would that be equivalent to the built-in support for rdfs:subClassOf? Is it 
something a SHACL validation processor could do by default?

Best,
Tom

-- 
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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/b7011fd4-7920-4238-b931-9410a55fd723n%40googlegroups.com.