e Ray
Sent: Friday, October 29, 2021 12:08 AM
To: TopBraid Suite Users
Subject: Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes
Michel,
It helped in the following specific case where I don't need to include a "$this
a/rdfs:subClassOf " statement. All my defined classes are
I'm not sure I fully understand why, but I changed my root class to be a
subClass of rdfs:Resource instead of rdfs:Class as you suggested, and the
odd behavior of all my instances suddenly being inferred to be subClasses
of rdfs:Resource went away. So thank you.
Steve
On Thu, Oct 28, 2021 at
Michel,
It helped in the following specific case where I don't need to include a
"$this a/rdfs:subClassOf " statement. All my defined classes
are instances of s223:Class. All the imported classes from various other
ontologies are not.
s223:Class
sh:property [
sh:path rdfs:label ;
sh:sparql [
a
I do understand that an own generic rootclass can help but not how an own "owl
class" can support that.
Op 28 okt. 2021 21:53 schreef Steve Ray :
Michel,
I was doing it similar to what you suggest, but making our own version of
owl:Class made it slightly easier to collect all the locally
Michel,
I was doing it similar to what you suggest, but making our own version of
owl:Class made it slightly easier to collect all the locally defined
classes for validation/inferencing. Don't have to have
a/rdfs:subClassOf* in my queries when validating all our defined classes. I
suppose it's a
I agree. When I run the SHACL reasoner with the following code, I get all
the inverse triples.
s223:InversePropertyShape
a sh:NodeShape ;
sh:rule [
a sh:SPARQLRule ;
sh:construct """
CONSTRUCT {
?o ?invP $this .
}
WHERE {
$this ?p ?o .
?p s223:inverseOf ?invP .
}
""" ;
sh:prefixes
myNamespace:MyRootClass
rdf:type rdfs:Class ;
rdf:type sh:NodeShape ;
rdfs:subClassOf rdfs:Resource ;
> On Oct 28, 2021, at 2:33 PM, Steve Ray wrote:
>
> One last(?) guidance request.
> Previously, I had been declaring classes as:
>
> ex:MyRandomClass
> rdf:type owl:Class ;
>
In SHACL, you give a name to the inverse relation by creating a property shape
with the inverse path. For example:
skos:Concept-broader-inverse
a sh:PropertyShape ;
sh:path [
sh:inversePath skos:broader ;
] ;
sh:class skos:Concept ;
sh:name "narrower concept" ;
.
This is the
Cant see why you would need an owndefined owlclass in your no owl rdfs
Just type your random classes as rdfs class and subclass them wrt your
rootclass itself also of type rdfs class.
Op 28 okt. 2021 20:49 schreef David Price :
Hi Steve
Rdfs subclass is between RDFS Class as a set
Hi Steve
Rdfs subclass is between RDFS Class as a set theory relation (all Sub are
Super) and type is from RDF to define set membership (Ind is a member of Sub)
Cheers,
David
> On 28 Oct 2021, at 19:33, Steve Ray wrote:
>
>
> One last(?) guidance request.
> Previously, I had been
One last(?) guidance request.
Previously, I had been declaring classes as:
ex:MyRandomClass
rdf:type owl:Class ;
rdf:type sh:NodeShape ;
rdfs:subClassOf owl:Thing ;
...
Normally, I define a root class in my ontologies, and all my other classes
are subclasses of that:
Yes, you are correct - I meant the use of owl:inverseOf, for which I infer
the inverse triple. I agree with you about not needing this, but it seems
some on the committee like being able to refer to the inverse relation by a
more familiar relation name. I may try one more time to argue to
On 2021-10-27 10:40 am, Steve Ray wrote:
Thanks Holger and Irene for this perspective.
Regarding properties, are you saying I should just declare all my
properties to be of type rdf:Property? I'm reluctant to just have them
all embedded inside property shapes, just for clarity.
This is your
Thanks Holger and Irene for this perspective.
Regarding properties, are you saying I should just declare all my
properties to be of type rdf:Property? I'm reluctant to just have them all
embedded inside property shapes, just for clarity.
Also, I have written SHACL rules to infer reverse triples
Please see below.
> On Oct 22, 2021, at 7:54 PM, Steve Ray wrote:
>
> I now understand.
>
> On a related point, is it true that the only owl uses that persist in SHACL
> implementations are the two relating to managing graphs:
>
> owl:imports (if you want to import other graphs), and
Yes,
On 2021-10-23 9:54 am, Steve Ray wrote:
I now understand.
On a related point, is it true that the only owl uses that persist in
SHACL implementations are the two relating to managing graphs:
owl:imports (if you want to import other graphs), and
This is the only use of OWL vocabulary in
I now understand.
On a related point, is it true that the only owl uses that persist in
SHACL implementations are the two relating to managing graphs:
owl:imports (if you want to import other graphs), and
X a owl:Ontology (if you want to name a graph so that you can do things
like imports)?
Do
> On 23 Oct 2021, at 3:50 am, Steve Ray wrote:
>
> Holger,
>
> Your final suggestion was the key! Who knew that we must declare owl:Class to
> be of type sh:NodeShape!
> I had a similar validation test for labelling all properties, and declaring
> rdf:Property as rdf:type sh:NodeShape fixed
Holger,
Your final suggestion was the key! Who knew that we must declare owl:Class
to be of type sh:NodeShape!
I had a similar validation test for labelling all properties, and declaring
rdf:Property as rdf:type sh:NodeShape fixed that one as well.
Thank you so much for that subtle tip. If this
Hi Steve,
it SHOULD work, but TBC has two validation buttons and only the green
one includes the classes and properties:
On 2021-10-22 8:09 am, Steve Ray wrote:
I'm not understanding something about validating SHACL files. Normally
I successfully use shapes and SPARQLConstraints to validate
I'm not understanding something about validating SHACL files. Normally I
successfully use shapes and SPARQLConstraints to validate rdf instance
files, but I'd also like to apply some constraints to our SHACL shape
definitions themselves.
For example, I'd like to ensure all our declared
21 matches
Mail list logo
