date:20211028

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

2021-10-28 Thread Steve Ray

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 12:20 PM Irene Polikoff 
wrote:

> 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 ;
>   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:
>
> myNamespace:MyRootClass
>   rdf:type owl:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf owl:Thing ;
>
> So in my no-OWL migration, I have defined my own non-OWL version of
> owl:Class:
>
> myNamespace:Class
>   rdf:type rdfs:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf rdfs:Class ;
>
> so my random classes would be:
>
>   ex:MyRandomClass
>   rdf:type myNamespace:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf myNamespace:MyRootClass ;
>
> so should my new root class be:
>
> myNamespace:MyRootClass
>   rdf:type myNamespace:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf rdfs:Class ;
>
> or should it be:
>
> myNamespace:MyRootClass
>   rdf:type myNamespace:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf rdfs:Resource ;
>
>
> ...I'm starting to confuse myself about things being a subClassOf
> something and being an rdf:type of something else. (I think I was absent
> during that session of semantic web 101!)
> I'm thinking the first one, but does the SHACL/rdf world even need both a
> type and a subClass?
> I realize that SHACL will just ignore the OWL stuff, but I'd like to go
> ahead and not have it there to avoid confusion.
>
> Steve
>
>
>
>
> On Tue, Oct 26, 2021 at 6:52 PM Holger Knublauch 
> wrote:
>
>>
>> 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 choice. SHACL or TopBraid doesn't require global
>> rdf:Property triples (except in some older code places which are now
>> considered bugs). If however you want to produce a generic ontology that is
>> also useful for external RDFS/OWL tools, then rdf:type rdf:Property is not
>> harmful. But you'd need to make sure they don't get out of synch, e.g.
>> after renaming the property.
>>
>>
>> Also, I have written SHACL rules to infer reverse triples for
>> owl:SymmetricProperty and owl:InverseProperty declarations, but I suppose I
>> could declare them as myNamespace:SymmetricProperty and
>> myNamespace:InverseProperty which could be subClassOf rdf:Property. Would
>> that be best practice?
>>
>> I assume you mean owl:inverseOf?
>>
>> It is perfectly fine to use SHACL rules that react on the OWL vocabulary,
>> e.g. owl:SymmetricProperty.
>>
>> FYI there is also a SHACL constraint in the dash: namespace that serves
>> not as inference but as a constraint
>>
>> https://datashapes.org/constraints.html#SymmetricConstraintComponent
>>
>> I don't like using owl:inverseOf and strongly discourage its use.
>> sh:inversePath is sufficient and doesn't require the use of an (OWL)
>> inference engine.
>>
>> Holger
>>
>>
>>
>> Steve
>>
>>
>>
>>
>> On Fri, Oct 22, 2021 at 5:32 PM Irene Polikoff 
>> wrote:
>>
>>> 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, explicitly supported in SHACL e.g.,
>>> https://www.w3.org/TR/shacl/#shapes-graph
>>>
>>> X a owl:Ontology (if you want to name a graph so that you can do things
>>> like imports)?
>>>
>>>
>>> Not really supported/required, but you can use it if you want.
>>>
>>>
>>> Do you endorse the use of owl property declarations, e.g. Y a
>>> owl:ObjectProperty, etc., or do you recommend enforcing the implications of
>>> those with SHACL shapes? If the latter, are there SHACL definitions for
>>> those?
>>>
>>>
>>> In general, we do not recommend the use of property declarations. SHACL
>>> will ignore them. However, if you wanted to, you could use them - as long
>>> as you understand that they have no meaning to SHACL.
>>>
>>> If you say:
>>>
>>> :PS a sh:PropertyShape;
>>> sh:path :p;
>>> sh:nodeKind sh:BlankNodeOrIRI ( sh:IRI or sh:BlankNode)
>>>
>>> You have effectively said that :p is used to connect two resources. If
>>> you know what class values of

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

2021-10-28 Thread Steve Ray

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 sh:SPARQLConstraint ;
sh:message "{$this} must have an rdfs:label" ;
sh:prefixes  ;
sh:select """
SELECT $this
WHERE {
FILTER (NOT EXISTS {$this rdfs:label ?something}) .
}
""" ;
] ;
] ;
.
Steve




On Thu, Oct 28, 2021 at 1:00 PM 'Bohms, H.M. (Michel)' via TopBraid Suite
Users  wrote:

> 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 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 style/judgment call.
>
> Steve
>
>
>
>
> On Thu, Oct 28, 2021 at 11:59 AM 'Bohms, H.M. (Michel)' via TopBraid Suite
> Users  wrote:
>
>>  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 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 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:
>>
>> myNamespace:MyRootClass
>>
>>   rdf:type owl:Class ;
>>
>>   rdf:type sh:NodeShape ;
>>
>>   rdfs:subClassOf owl:Thing ;
>>
>> So in my no-OWL migration, I have defined my own non-OWL version of
>> owl:Class:
>>
>>
>> myNamespace:Class
>>
>>   rdf:type rdfs:Class ;
>>
>>   rdf:type sh:NodeShape ;
>>
>>   rdfs:subClassOf rdfs:Class ;
>>
>> so my random classes would be:
>>
>>   ex:MyRandomClass
>>
>>   rdf:type myNamespace:Class ;
>>
>>   rdf:type sh:NodeShape ;
>>
>>   rdfs:subClassOf myNamespace:MyRootClass ;
>>
>> so should my new root class be:
>>
>> myNamespace:MyRootClass
>>
>>   rdf:type myNamespace:Class ;
>>
>>   rdf:type sh:NodeShape ;
>>
>>   rdfs:subClassOf rdfs:Class ;
>>
>>
>> or should it be:
>>
>>
>> myNamespace:MyRootClass
>>
>>   rdf:type myNamespace:Class ;
>>
>>   rdf:type sh:NodeShape ;
>>
>>   rdfs:subClassOf rdfs:Resource ;
>>
>>
>> ...I'm starting to confuse myself about things being a subClassOf
>> something and being an rdf:type of something else. (I think I was absent
>> during that session of semantic web 101!)
>> I'm thinking the first one, but does the SHACL/rdf world even need both a
>> type and a subClass?
>> I realize that SHACL will just ignore the OWL stuff, but I'd like to go
>> ahead and not have it there to avoid confusion.
>>
>> Steve
>>
>>
>>
>>
>> On Tue, Oct 26, 2021 at 6:52 PM Holger Knublauch 
>> wrote:
>>
>>>
>>> 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 choice. SHACL or TopBraid doesn't require global
>>> rdf:Property triples (except in some older code places which are now
>>> considered bugs). If however you want to produce a generic ontology that is
>>> also useful for external RDFS/OWL tools, then rdf:type rdf:Property is not
>>> harmful. But you'd need to make sure they don't get out of synch, e.g.
>>> after renaming the property.
>>>
>>>
>>> Also, I have written SHACL rules to infer reverse triples for
>>> owl:SymmetricProperty and owl:InverseProperty declarations, but I suppose I
>>> could declare them as myNamespace:SymmetricProperty and
>>> myNamespace:InverseProperty which could be subClassOf rdf:Property. Would
>>> that be best practice?
>>>
>>> I assume you mean owl:inverseOf?
>>>
>>> It is perfectly fine to use SHACL rules that react on the OWL
>>> vocabulary, e.g. owl:SymmetricProperty.
>>>
>>> FYI there is also a SHACL constraint in the dash: namespace that serves
>>> not as inference but as a constraint
>>>
>>> https://datashapes.org/constraints.html#SymmetricConstraintComponent
>>>
>>> I don't like using owl:inverseOf and strongly discourage its use.
>>> sh:inversePath is sufficient and doesn't require the use of an (OW

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

2021-10-28 Thread 'Bohms, H.M. (Michel)' via TopBraid Suite Users

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 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 style/judgment call.

Steve




On Thu, Oct 28, 2021 at 11:59 AM 'Bohms, H.M. (Michel)' via TopBraid Suite 
Users mailto:topbraid-users@googlegroups.com>> 
wrote:
 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 
mailto:dpr...@topquadrant.com>>:
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 
mailto:st...@steveray.com>> wrote:


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:

myNamespace:MyRootClass

  rdf:type owl:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf owl:Thing ;

So in my no-OWL migration, I have defined my own non-OWL version of owl:Class:


myNamespace:Class

  rdf:type rdfs:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf rdfs:Class ;

so my random classes would be:


  ex:MyRandomClass

  rdf:type myNamespace:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf myNamespace:MyRootClass ;

so should my new root class be:

myNamespace:MyRootClass

  rdf:type myNamespace:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf rdfs:Class ;


or should it be:


myNamespace:MyRootClass

  rdf:type myNamespace:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf rdfs:Resource ;



...I'm starting to confuse myself about things being a subClassOf something and 
being an rdf:type of something else. (I think I was absent during that session 
of semantic web 101!)
I'm thinking the first one, but does the SHACL/rdf world even need both a type 
and a subClass?
I realize that SHACL will just ignore the OWL stuff, but I'd like to go ahead 
and not have it there to avoid confusion.

Steve




On Tue, Oct 26, 2021 at 6:52 PM Holger Knublauch 
mailto:hol...@topquadrant.com>> wrote:


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 choice. SHACL or TopBraid doesn't require global rdf:Property 
triples (except in some older code places which are now considered bugs). If 
however you want to produce a generic ontology that is also useful for external 
RDFS/OWL tools, then rdf:type rdf:Property is not harmful. But you'd need to 
make sure they don't get out of synch, e.g. after renaming the property.

Also, I have written SHACL rules to infer reverse triples for 
owl:SymmetricProperty and owl:InverseProperty declarations, but I suppose I 
could declare them as myNamespace:SymmetricProperty and 
myNamespace:InverseProperty which could be subClassOf rdf:Property. Would that 
be best practice?

I assume you mean owl:inverseOf?

It is perfectly fine to use SHACL rules that react on the OWL vocabulary, e.g. 
owl:SymmetricProperty.

FYI there is also a SHACL constraint in the dash: namespace that serves not as 
inference but as a constraint

https://datashapes.org/constraints.html#SymmetricConstraintComponent

I don't like using owl:inverseOf and strongly discourage its use. 
sh:inversePath is sufficient and doesn't require the use of an (OWL) inference 
engine.

Holger


Steve




On Fri, Oct 22, 2021 at 5:32 PM Irene Polikoff 
mailto:ir...@topquadrant.com>> wrote:
Please see below.

On Oct 22, 2021, at 7:54 PM, Steve Ray 
mailto:st...@steveray.com>> 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, explicitly supported in SHACL e.g., 
https://www.w3.org/TR/shacl/#shapes-graph

X a owl:Ontology (if you want to name a graph so that you can do things like 
imports)?

Not really supported/required, but you can use it if you want.

Do you endorse the use of owl property declarations, e.g. Y a 
owl:ObjectProperty, etc., or do you recommend enforcing the implications of 
those with SHACL shapes? If the latter, are there SHACL definitions for those?

In general, we do no

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

2021-10-28 Thread 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 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 style/judgment call.

Steve




On Thu, Oct 28, 2021 at 11:59 AM 'Bohms, H.M. (Michel)' via TopBraid Suite
Users  wrote:

>  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 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 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:
>
> myNamespace:MyRootClass
>
>   rdf:type owl:Class ;
>
>   rdf:type sh:NodeShape ;
>
>   rdfs:subClassOf owl:Thing ;
>
> So in my no-OWL migration, I have defined my own non-OWL version of
> owl:Class:
>
>
> myNamespace:Class
>
>   rdf:type rdfs:Class ;
>
>   rdf:type sh:NodeShape ;
>
>   rdfs:subClassOf rdfs:Class ;
>
> so my random classes would be:
>
>   ex:MyRandomClass
>
>   rdf:type myNamespace:Class ;
>
>   rdf:type sh:NodeShape ;
>
>   rdfs:subClassOf myNamespace:MyRootClass ;
>
> so should my new root class be:
>
> myNamespace:MyRootClass
>
>   rdf:type myNamespace:Class ;
>
>   rdf:type sh:NodeShape ;
>
>   rdfs:subClassOf rdfs:Class ;
>
>
> or should it be:
>
>
> myNamespace:MyRootClass
>
>   rdf:type myNamespace:Class ;
>
>   rdf:type sh:NodeShape ;
>
>   rdfs:subClassOf rdfs:Resource ;
>
>
> ...I'm starting to confuse myself about things being a subClassOf
> something and being an rdf:type of something else. (I think I was absent
> during that session of semantic web 101!)
> I'm thinking the first one, but does the SHACL/rdf world even need both a
> type and a subClass?
> I realize that SHACL will just ignore the OWL stuff, but I'd like to go
> ahead and not have it there to avoid confusion.
>
> Steve
>
>
>
>
> On Tue, Oct 26, 2021 at 6:52 PM Holger Knublauch 
> wrote:
>
>>
>> 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 choice. SHACL or TopBraid doesn't require global
>> rdf:Property triples (except in some older code places which are now
>> considered bugs). If however you want to produce a generic ontology that is
>> also useful for external RDFS/OWL tools, then rdf:type rdf:Property is not
>> harmful. But you'd need to make sure they don't get out of synch, e.g.
>> after renaming the property.
>>
>>
>> Also, I have written SHACL rules to infer reverse triples for
>> owl:SymmetricProperty and owl:InverseProperty declarations, but I suppose I
>> could declare them as myNamespace:SymmetricProperty and
>> myNamespace:InverseProperty which could be subClassOf rdf:Property. Would
>> that be best practice?
>>
>> I assume you mean owl:inverseOf?
>>
>> It is perfectly fine to use SHACL rules that react on the OWL vocabulary,
>> e.g. owl:SymmetricProperty.
>>
>> FYI there is also a SHACL constraint in the dash: namespace that serves
>> not as inference but as a constraint
>>
>> https://datashapes.org/constraints.html#SymmetricConstraintComponent
>>
>> I don't like using owl:inverseOf and strongly discourage its use.
>> sh:inversePath is sufficient and doesn't require the use of an (OWL)
>> inference engine.
>>
>> Holger
>>
>>
>>
>> Steve
>>
>>
>>
>>
>> On Fri, Oct 22, 2021 at 5:32 PM Irene Polikoff 
>> wrote:
>>
>>> 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, explicitly supported in SHACL e.g.,
>>> https://www.w3.org/TR/shacl/#shapes-graph
>>>
>>> X a owl:Ontology (if you want to name a graph so that you can do things
>>> like imports)?
>>>
>>>
>>> Not really supported/required, but you can use it if you want.
>>>
>>>
>>> Do you endorse the use of owl property declarations, e.g. Y a
>>> owl:ObjectProperty, etc., or do you recommend enforcing the implications of
>>> those with SHACL shapes? If the latter, are there SHACL definitions for
>>> those?
>>>
>>>
>

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

2021-10-28 Thread Steve Ray

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  ;
] ;
sh:targetClass s223:Concept ;
.

Your point is well taken that we could do it your way without running the
reasoner, although we run it anyway for other inferences.

Steve




On Thu, Oct 28, 2021 at 12:18 PM Irene Polikoff 
wrote:

> 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 true notion of the inverse relation in a graph because it
> describes traversing a relationship in an opposite direction and it gives a
> name to the opposite direction.
>
> When you declare a separate URI for a property and say that it is an
> inverse e.g.,
>
> skos:narrower owl:inverseOf skos:broader.
>
> And then talk about triples that use the skos:narrower predicate, strictly
> speaking, you are not really talking about triples with the skos:broader
> relationship that exist in your graph - whether you traverse such triples
> in one direction or in another. At most, you are talking about skos:broader
> triples that would get generated from the skos:narrower should a reasoner
> be applied.
>
> On Oct 27, 2021, at 12:41 PM, Steve Ray  wrote:
>
> 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 eliminate
> our inverse properties.
>
> Regarding the owl:SymmetricProperty declaration, I plan to go ahead and
> replace it with a mynamespace:SymmetricProperty declaration, since I wrote
> the SHACL inference rule anyway. One less OWL element in the model.
>
> Steve
>
>
>
>
> On Tue, Oct 26, 2021 at 6:52 PM Holger Knublauch 
> wrote:
>
>>
>> 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 choice. SHACL or TopBraid doesn't require global
>> rdf:Property triples (except in some older code places which are now
>> considered bugs). If however you want to produce a generic ontology that is
>> also useful for external RDFS/OWL tools, then rdf:type rdf:Property is not
>> harmful. But you'd need to make sure they don't get out of synch, e.g.
>> after renaming the property.
>>
>>
>> Also, I have written SHACL rules to infer reverse triples for
>> owl:SymmetricProperty and owl:InverseProperty declarations, but I suppose I
>> could declare them as myNamespace:SymmetricProperty and
>> myNamespace:InverseProperty which could be subClassOf rdf:Property. Would
>> that be best practice?
>>
>> I assume you mean owl:inverseOf?
>>
>> It is perfectly fine to use SHACL rules that react on the OWL vocabulary,
>> e.g. owl:SymmetricProperty.
>>
>> FYI there is also a SHACL constraint in the dash: namespace that serves
>> not as inference but as a constraint
>>
>> https://datashapes.org/constraints.html#SymmetricConstraintComponent
>>
>> I don't like using owl:inverseOf and strongly discourage its use.
>> sh:inversePath is sufficient and doesn't require the use of an (OWL)
>> inference engine.
>>
>> Holger
>>
>>
>>
>> Steve
>>
>>
>>
>>
>> On Fri, Oct 22, 2021 at 5:32 PM Irene Polikoff 
>> wrote:
>>
>>> 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, explicitly supported in SHACL e.g.,
>>> https://www.w3.org/TR/shacl/#shapes-graph
>>>
>>> X a owl:Ontology (if you want to name a graph so that you can do things
>>> like imports)?
>>>
>>>
>>> Not really supported/required, but you can use it if you want.
>>>
>>>
>>> Do you endorse the use of owl property declarations, e.g. Y a
>>> owl:ObjectProperty, etc., or do you recommend enforcing the implications of
>>> those with SHACL shapes? If the latter, are there SHACL definitions for
>>> those?
>>>
>>>
>>> In general, we do not recommend the use of property declarations. SHACL
>>> will ignore them. However, if you wanted to, you could use them - as long
>>> as you understand that they have no meaning to SHACL.
>>>
>>> If you say:
>>>

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

2021-10-28 Thread Irene Polikoff

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 ;
>   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:
> 
> myNamespace:MyRootClass  
>   rdf:type owl:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf owl:Thing ;
> 
> So in my no-OWL migration, I have defined my own non-OWL version of owl:Class:
> 
> myNamespace:Class
>   rdf:type rdfs:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf rdfs:Class ;
> 
> so my random classes would be:
> 
>   ex:MyRandomClass 
>   rdf:type myNamespace:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf myNamespace:MyRootClass ;
> 
> so should my new root class be:
> 
> myNamespace:MyRootClass  
>   rdf:type myNamespace:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf rdfs:Class ;
> 
> or should it be:
> 
> myNamespace:MyRootClass  
>   rdf:type myNamespace:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf rdfs:Resource ;
> 
> 
> ...I'm starting to confuse myself about things being a subClassOf something 
> and being an rdf:type of something else. (I think I was absent during that 
> session of semantic web 101!)
> I'm thinking the first one, but does the SHACL/rdf world even need both a 
> type and a subClass?
> I realize that SHACL will just ignore the OWL stuff, but I'd like to go ahead 
> and not have it there to avoid confusion.
> 
> Steve
> 
> 
> 
> 
> On Tue, Oct 26, 2021 at 6:52 PM Holger Knublauch  > wrote:
> 
> 
> 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 choice. SHACL or TopBraid doesn't require global rdf:Property 
> triples (except in some older code places which are now considered bugs). If 
> however you want to produce a generic ontology that is also useful for 
> external RDFS/OWL tools, then rdf:type rdf:Property is not harmful. But you'd 
> need to make sure they don't get out of synch, e.g. after renaming the 
> property.
>> 
>> Also, I have written SHACL rules to infer reverse triples for 
>> owl:SymmetricProperty and owl:InverseProperty declarations, but I suppose I 
>> could declare them as myNamespace:SymmetricProperty and 
>> myNamespace:InverseProperty which could be subClassOf rdf:Property. Would 
>> that be best practice?
> I assume you mean owl:inverseOf?
> 
> It is perfectly fine to use SHACL rules that react on the OWL vocabulary, 
> e.g. owl:SymmetricProperty.
> 
> FYI there is also a SHACL constraint in the dash: namespace that serves not 
> as inference but as a constraint
> 
> https://datashapes.org/constraints.html#SymmetricConstraintComponent 
> 
> I don't like using owl:inverseOf and strongly discourage its use. 
> sh:inversePath is sufficient and doesn't require the use of an (OWL) 
> inference engine.
> 
> Holger
> 
> 
> 
>> 
>> Steve
>> 
>> 
>> 
>> 
>> On Fri, Oct 22, 2021 at 5:32 PM Irene Polikoff > > wrote:
>> 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, explicitly supported in SHACL e.g., 
>> https://www.w3.org/TR/shacl/#shapes-graph 
>> 
>> 
>>> X a owl:Ontology (if you want to name a graph so that you can do things 
>>> like imports)?
>> 
>> Not really supported/required, but you can use it if you want.
>>> 
>>> Do you endorse the use of owl property declarations, e.g. Y a 
>>> owl:ObjectProperty, etc., or do you recommend enforcing the implications of 
>>> those with SHACL shapes? If the latter, are there SHACL definitions for 
>>> those?
>> 
>> In general, we do not recommend the use of property declarations. SHACL will 
>> ignore them. However, if you wanted to, you could use them - as long as you 
>> understand that they have no meaning to SHACL.
>> 
>> If you say:
>> 
>> :PS a sh:PropertyShape;
>> sh:path :p;
>> sh:nodeKind sh:BlankNodeOrIRI ( sh:IRI or sh:BlankNode)
>> 
>> You have effectively said that :p is used to connect two resources. If you 
>> know what class values of :p belong to, you could also say:
>> 
>> :PS a sh:PropertyShape;
>> sh:path :p;
>> sh:class :C .
>> 
>> Th

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

2021-10-28 Thread Irene Polikoff

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 true notion of the inverse relation in a graph because it describes 
traversing a relationship in an opposite direction and it gives a name to the 
opposite direction.

When you declare a separate URI for a property and say that it is an inverse 
e.g.,

skos:narrower owl:inverseOf skos:broader.

And then talk about triples that use the skos:narrower predicate, strictly 
speaking, you are not really talking about triples with the skos:broader 
relationship that exist in your graph - whether you traverse such triples in 
one direction or in another. At most, you are talking about skos:broader 
triples that would get generated from the skos:narrower should a reasoner be 
applied.

> On Oct 27, 2021, at 12:41 PM, Steve Ray  wrote:
> 
> 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 eliminate 
> our inverse properties.
> 
> Regarding the owl:SymmetricProperty declaration, I plan to go ahead and 
> replace it with a mynamespace:SymmetricProperty declaration, since I wrote 
> the SHACL inference rule anyway. One less OWL element in the model.
> 
> Steve
> 
> 
> 
> 
> On Tue, Oct 26, 2021 at 6:52 PM Holger Knublauch  > wrote:
> 
> 
> 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 choice. SHACL or TopBraid doesn't require global rdf:Property 
> triples (except in some older code places which are now considered bugs). If 
> however you want to produce a generic ontology that is also useful for 
> external RDFS/OWL tools, then rdf:type rdf:Property is not harmful. But you'd 
> need to make sure they don't get out of synch, e.g. after renaming the 
> property.
>> 
>> Also, I have written SHACL rules to infer reverse triples for 
>> owl:SymmetricProperty and owl:InverseProperty declarations, but I suppose I 
>> could declare them as myNamespace:SymmetricProperty and 
>> myNamespace:InverseProperty which could be subClassOf rdf:Property. Would 
>> that be best practice?
> I assume you mean owl:inverseOf?
> 
> It is perfectly fine to use SHACL rules that react on the OWL vocabulary, 
> e.g. owl:SymmetricProperty.
> 
> FYI there is also a SHACL constraint in the dash: namespace that serves not 
> as inference but as a constraint
> 
> https://datashapes.org/constraints.html#SymmetricConstraintComponent 
> 
> I don't like using owl:inverseOf and strongly discourage its use. 
> sh:inversePath is sufficient and doesn't require the use of an (OWL) 
> inference engine.
> 
> Holger
> 
> 
> 
>> 
>> Steve
>> 
>> 
>> 
>> 
>> On Fri, Oct 22, 2021 at 5:32 PM Irene Polikoff > > wrote:
>> 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, explicitly supported in SHACL e.g., 
>> https://www.w3.org/TR/shacl/#shapes-graph 
>> 
>> 
>>> X a owl:Ontology (if you want to name a graph so that you can do things 
>>> like imports)?
>> 
>> Not really supported/required, but you can use it if you want.
>>> 
>>> Do you endorse the use of owl property declarations, e.g. Y a 
>>> owl:ObjectProperty, etc., or do you recommend enforcing the implications of 
>>> those with SHACL shapes? If the latter, are there SHACL definitions for 
>>> those?
>> 
>> In general, we do not recommend the use of property declarations. SHACL will 
>> ignore them. However, if you wanted to, you could use them - as long as you 
>> understand that they have no meaning to SHACL.
>> 
>> If you say:
>> 
>> :PS a sh:PropertyShape;
>> sh:path :p;
>> sh:nodeKind sh:BlankNodeOrIRI ( sh:IRI or sh:BlankNode)
>> 
>> You have effectively said that :p is used to connect two resources. If you 
>> know what class values of :p belong to, you could also say:
>> 
>> :PS a sh:PropertyShape;
>> sh:path :p;
>> sh:class :C .
>> 
>> This would also indicate that the property connects two resources, but it 
>> says m

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

2021-10-28 Thread 'Bohms, H.M. (Michel)' via TopBraid Suite Users

 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 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 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:

myNamespace:MyRootClass

  rdf:type owl:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf owl:Thing ;

So in my no-OWL migration, I have defined my own non-OWL version of owl:Class:


myNamespace:Class

  rdf:type rdfs:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf rdfs:Class ;

so my random classes would be:


  ex:MyRandomClass

  rdf:type myNamespace:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf myNamespace:MyRootClass ;

so should my new root class be:

myNamespace:MyRootClass

  rdf:type myNamespace:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf rdfs:Class ;


or should it be:


myNamespace:MyRootClass

  rdf:type myNamespace:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf rdfs:Resource ;



...I'm starting to confuse myself about things being a subClassOf something and 
being an rdf:type of something else. (I think I was absent during that session 
of semantic web 101!)
I'm thinking the first one, but does the SHACL/rdf world even need both a type 
and a subClass?
I realize that SHACL will just ignore the OWL stuff, but I'd like to go ahead 
and not have it there to avoid confusion.

Steve




On Tue, Oct 26, 2021 at 6:52 PM Holger Knublauch 
mailto:hol...@topquadrant.com>> wrote:


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 choice. SHACL or TopBraid doesn't require global rdf:Property 
triples (except in some older code places which are now considered bugs). If 
however you want to produce a generic ontology that is also useful for external 
RDFS/OWL tools, then rdf:type rdf:Property is not harmful. But you'd need to 
make sure they don't get out of synch, e.g. after renaming the property.

Also, I have written SHACL rules to infer reverse triples for 
owl:SymmetricProperty and owl:InverseProperty declarations, but I suppose I 
could declare them as myNamespace:SymmetricProperty and 
myNamespace:InverseProperty which could be subClassOf rdf:Property. Would that 
be best practice?

I assume you mean owl:inverseOf?

It is perfectly fine to use SHACL rules that react on the OWL vocabulary, e.g. 
owl:SymmetricProperty.

FYI there is also a SHACL constraint in the dash: namespace that serves not as 
inference but as a constraint

https://datashapes.org/constraints.html#SymmetricConstraintComponent

I don't like using owl:inverseOf and strongly discourage its use. 
sh:inversePath is sufficient and doesn't require the use of an (OWL) inference 
engine.

Holger


Steve




On Fri, Oct 22, 2021 at 5:32 PM Irene Polikoff 
mailto:ir...@topquadrant.com>> wrote:
Please see below.

On Oct 22, 2021, at 7:54 PM, Steve Ray 
mailto:st...@steveray.com>> 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, explicitly supported in SHACL e.g., 
https://www.w3.org/TR/shacl/#shapes-graph

X a owl:Ontology (if you want to name a graph so that you can do things like 
imports)?

Not really supported/required, but you can use it if you want.

Do you endorse the use of owl property declarations, e.g. Y a 
owl:ObjectProperty, etc., or do you recommend enforcing the implications of 
those with SHACL shapes? If the latter, are there SHACL definitions for those?

In general, we do not recommend the use of property declarations. SHACL will 
ignore them. However, if you wanted to, you could use them - as long as you 
understand that they have no meaning to SHACL.

If you say:

:PS a sh:PropertyShape;
sh:path :p;
sh:nodeKind sh:BlankNodeOrIRI ( sh:IRI or sh:BlankNode)

You have effectively said that :p is used to connect two resources. If you know 
what class values of :p belong to, you could also say:

:PS a sh:PropertyShape;
sh:path :p;
sh:class :C .

This would also indicate that the property connects two resources, but it says 
more than that. Using both, sh:class constraint and sh:nodeKind 
sh:BlankNodeOrIRI is redundant.

If yo

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

2021-10-28 Thread David Price

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 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:
> 
> myNamespace:MyRootClass  
>   rdf:type owl:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf owl:Thing ;
> 
> So in my no-OWL migration, I have defined my own non-OWL version of owl:Class:
> 
> myNamespace:Class
>   rdf:type rdfs:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf rdfs:Class ;
> 
> so my random classes would be:
> 
>   ex:MyRandomClass 
>   rdf:type myNamespace:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf myNamespace:MyRootClass ;
> 
> so should my new root class be:
> 
> myNamespace:MyRootClass  
>   rdf:type myNamespace:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf rdfs:Class ;
> 
> or should it be:
> 
> myNamespace:MyRootClass  
>   rdf:type myNamespace:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf rdfs:Resource ;
> 
> 
> ...I'm starting to confuse myself about things being a subClassOf something 
> and being an rdf:type of something else. (I think I was absent during that 
> session of semantic web 101!)
> I'm thinking the first one, but does the SHACL/rdf world even need both a 
> type and a subClass?
> I realize that SHACL will just ignore the OWL stuff, but I'd like to go ahead 
> and not have it there to avoid confusion.
> 
> Steve
> 
> 
> 
> 
>> On Tue, Oct 26, 2021 at 6:52 PM Holger Knublauch  
>> wrote:
>> 
>> 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 choice. SHACL or TopBraid doesn't require global rdf:Property 
>> triples (except in some older code places which are now considered bugs). If 
>> however you want to produce a generic ontology that is also useful for 
>> external RDFS/OWL tools, then rdf:type rdf:Property is not harmful. But 
>> you'd need to make sure they don't get out of synch, e.g. after renaming the 
>> property.
>>> 
>>> Also, I have written SHACL rules to infer reverse triples for 
>>> owl:SymmetricProperty and owl:InverseProperty declarations, but I suppose I 
>>> could declare them as myNamespace:SymmetricProperty and 
>>> myNamespace:InverseProperty which could be subClassOf rdf:Property. Would 
>>> that be best practice?
>> I assume you mean owl:inverseOf?
>> 
>> It is perfectly fine to use SHACL rules that react on the OWL vocabulary, 
>> e.g. owl:SymmetricProperty.
>> 
>> FYI there is also a SHACL constraint in the dash: namespace that serves not 
>> as inference but as a constraint
>> 
>> https://datashapes.org/constraints.html#SymmetricConstraintComponent
>> 
>> I don't like using owl:inverseOf and strongly discourage its use. 
>> sh:inversePath is sufficient and doesn't require the use of an (OWL) 
>> inference engine.
>> 
>> Holger
>> 
>> 
>> 
>>> 
>>> Steve
>>> 
>>> 
>>> 
>>> 
>>> On Fri, Oct 22, 2021 at 5:32 PM Irene Polikoff  
>>> wrote:
 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, explicitly supported in SHACL e.g., 
 https://www.w3.org/TR/shacl/#shapes-graph
 
> X a owl:Ontology (if you want to name a graph so that you can do things 
> like imports)?
 
 Not really supported/required, but you can use it if you want.
> 
> Do you endorse the use of owl property declarations, e.g. Y a 
> owl:ObjectProperty, etc., or do you recommend enforcing the implications 
> of those with SHACL shapes? If the latter, are there SHACL definitions 
> for those?
 
 In general, we do not recommend the use of property declarations. SHACL 
 will ignore them. However, if you wanted to, you could use them - as long 
 as you understand that they have no meaning to SHACL.
 
 If you say:
 
 :PS a sh:PropertyShape;
 sh:path :p;
 sh:nodeKind sh:BlankNodeOrIRI ( sh:IRI or sh:BlankNode)
 
 You have effectively said that :p is used to connect two resources. If you 
 know what class values of :p belong to, you could also say:
 
 :PS a sh:PropertyShape;
 sh:path :p;
 sh:class :C .
 
 This would al

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

2021-10-28 Thread Steve Ray

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:

myNamespace:MyRootClass

  rdf:type owl:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf owl:Thing ;

So in my no-OWL migration, I have defined my own non-OWL version of
owl:Class:


myNamespace:Class

  rdf:type rdfs:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf rdfs:Class ;

so my random classes would be:

  ex:MyRandomClass

  rdf:type myNamespace:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf myNamespace:MyRootClass ;

so should my new root class be:

myNamespace:MyRootClass

  rdf:type myNamespace:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf rdfs:Class ;


or should it be:


myNamespace:MyRootClass

  rdf:type myNamespace:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf rdfs:Resource ;


...I'm starting to confuse myself about things being a subClassOf something
and being an rdf:type of something else. (I think I was absent during that
session of semantic web 101!)
I'm thinking the first one, but does the SHACL/rdf world even need both a
type and a subClass?
I realize that SHACL will just ignore the OWL stuff, but I'd like to go
ahead and not have it there to avoid confusion.

Steve




On Tue, Oct 26, 2021 at 6:52 PM Holger Knublauch 
wrote:

>
> 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 choice. SHACL or TopBraid doesn't require global rdf:Property
> triples (except in some older code places which are now considered bugs).
> If however you want to produce a generic ontology that is also useful for
> external RDFS/OWL tools, then rdf:type rdf:Property is not harmful. But
> you'd need to make sure they don't get out of synch, e.g. after renaming
> the property.
>
>
> Also, I have written SHACL rules to infer reverse triples for
> owl:SymmetricProperty and owl:InverseProperty declarations, but I suppose I
> could declare them as myNamespace:SymmetricProperty and
> myNamespace:InverseProperty which could be subClassOf rdf:Property. Would
> that be best practice?
>
> I assume you mean owl:inverseOf?
>
> It is perfectly fine to use SHACL rules that react on the OWL vocabulary,
> e.g. owl:SymmetricProperty.
>
> FYI there is also a SHACL constraint in the dash: namespace that serves
> not as inference but as a constraint
>
> https://datashapes.org/constraints.html#SymmetricConstraintComponent
>
> I don't like using owl:inverseOf and strongly discourage its use.
> sh:inversePath is sufficient and doesn't require the use of an (OWL)
> inference engine.
>
> Holger
>
>
>
> Steve
>
>
>
>
> On Fri, Oct 22, 2021 at 5:32 PM Irene Polikoff 
> wrote:
>
>> 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, explicitly supported in SHACL e.g.,
>> https://www.w3.org/TR/shacl/#shapes-graph
>>
>> X a owl:Ontology (if you want to name a graph so that you can do things
>> like imports)?
>>
>>
>> Not really supported/required, but you can use it if you want.
>>
>>
>> Do you endorse the use of owl property declarations, e.g. Y a
>> owl:ObjectProperty, etc., or do you recommend enforcing the implications of
>> those with SHACL shapes? If the latter, are there SHACL definitions for
>> those?
>>
>>
>> In general, we do not recommend the use of property declarations. SHACL
>> will ignore them. However, if you wanted to, you could use them - as long
>> as you understand that they have no meaning to SHACL.
>>
>> If you say:
>>
>> :PS a sh:PropertyShape;
>> sh:path :p;
>> sh:nodeKind sh:BlankNodeOrIRI ( sh:IRI or sh:BlankNode)
>>
>> You have effectively said that :p is used to connect two resources. If
>> you know what class values of :p belong to, you could also say:
>>
>> :PS a sh:PropertyShape;
>> sh:path :p;
>> sh:class :C .
>>
>> This would also indicate that the property connects two resources, but it
>> says more than that. Using both, sh:class constraint and sh:nodeKind
>> sh:BlankNodeOrIRI is redundant.
>>
>> If you are not able to identify the class, you could say sh:class
>> rdfs:Resource.
>>
>> Instead of  owl:Datatype property, you would use sh:nodeKind sh:Literal
>> or use sh:datatype constraint if you can be more specific and identify the
>> datatype. This is not one to one to OWL since OWL distinguishes between the
>> datatype and annotation properties because annotation pr

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

10 matches

Site Navigation

Mail list logo

Footer information