See https://twitter.com/wohnjalker/status/915982539747028992
As a slightly more serious response, I agree that URIs from the OWL
namespace may be useful even without OWL semantics. owl:imports is
clearly useful, and even referenced by the SHACL spec. owl:versionInfo
and the deprecation mechanisms can be useful, but they don't carry OWL
semantics. Whether owl:DatatypeProperty and owl:ObjectProperty provide
value is a matter of debate. I believe as long as there are sh:class and
sh:datatype or sh:nodeKind constraints in place, then there is no need
for them. I am not fond of global property axioms in general, but that's
another topic.
Maybe there is value in going through the ways that people have used OWL
so far and verify how many of them were really designed for OWL (DL)
inferencing. Maybe you have examples of axioms in your world, that you
could share here so that we can see what would be left that isn't
covered by SHACL or other non-OWL vocabularies.
Holger
On 6/10/2017 16:49, Bohms, H.M. (Michel) wrote:
Thx Holger, for the argumentation (SoC)!
Just….
I could see a scenario in future where in CWA-area OWL could be fully
replaced by SHACL (ie retire OWL). Because there are no dependencies
as you explain below there are certainly no technical restraints for
something like that.
But then…..aren’t we losing more that we want? Clearly we want to
replace OWA Restrictions to SHACL Shapes. But what about eg the
distinction in datatype properties and object properties and other
very useful OWL modelling constructs…ie wouldn’t there be a need for
an OWL Light or RDFS+ to combine cleanly with SHACL then?
Thanks very much for your views again,
Michel
Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist
T +31888663107
M +31630381220
E [email protected] <mailto:[email protected]>
Location
<https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=%213m1%214b1%214m5%213m4%211s0x47c5b58c52869997:0x56681566be3b8c88%218m2%213d52.000788%214d4.376707>
<http://www.tno.nl/>
This message may contain information that is not intended for you. If
you are not the addressee or if this message was sent to you by
mistake, you are requested to inform the sender and delete the
message. TNO accepts no liability for the content of this e-mail, for
the manner in which you use it and for damage of any kind resulting
from the risks inherent to the electronic transmission of messages.
*From:*[email protected]
[mailto:[email protected]] *On Behalf Of *Holger Knublauch
*Sent:* woensdag 4 oktober 2017 09:50
*To:* [email protected]
*Subject:* Re: [topbraid-users] owl-shacl question
The pros are that users that don't want/need to use OWL don't have to
import these axioms, and thus the RDF files that you are producing are
more focused - think of separation of concerns, which is generally a
good engineering practice. SHACL doesn't need OWL, OWL doesn't need
SHACL, so there is no reason to stack them on top of each other. If
projects plan ahead they can also more easily retire any part of their
stack that is no longer needed. Finally, having OWL axioms around may
create false expectations or confuse the view point from a SHACL
perspective (although the axioms are technically ignored, users may
expect inferencing to happen).
Holger
On 4/10/2017 17:28, Bohms, H.M. (Michel) wrote:
Ok, any pros for the new approach (compared to just owl-rdfs/shacl
split) very welcome,
Gr Michel
Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist
T +31888663107
M +31630381220
E [email protected] <mailto:[email protected]>
Location
<https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=%213m1%214b1%214m5%213m4%211s0x47c5b58c52869997:0x56681566be3b8c88%218m2%213d52.000788%214d4.376707>
<http://www.tno.nl/>
This message may contain information that is not intended for you.
If you are not the addressee or if this message was sent to you by
mistake, you are requested to inform the sender and delete the
message. TNO accepts no liability for the content of this e-mail,
for the manner in which you use it and for damage of any kind
resulting from the risks inherent to the electronic transmission
of messages.
*From:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]] *On Behalf Of *Holger
Knublauch
*Sent:* woensdag 4 oktober 2017 09:02
*To:* [email protected]
<mailto:[email protected]>
*Subject:* Re: [topbraid-users] owl-shacl question
Sure, that should work without problems. The suggested split is
mostly for new projects that are under your control.
Holger
Sent from my iPad
On 4 Oct 2017, at 16:49, Bohms, H.M. (Michel) <[email protected]
<mailto:[email protected]>> wrote:
Dear Irene, Holger
In http://spinrdf.org/shacl-and-owl.html it is suggested to
have the following ‘architecture’:
<image002.png>
Would I lose much benefit when I simplify a bit by just having
OWL/RDFS (with owl/rdfs owa inferencing) on top and (several)
SHACL views (with shacl cwa validation and inferencing (rule
part)) below. (I just mention ‘several’because typically there
are more validation-views possible working on the same
conceptual owl-view). Just looking for pros and cons. One of
the reasons is that in practically all existing ontologies
relevant for us do not have the split yet in rdfs and owl…just
an example: a very recent proposal that I really like:
https://www.w3.org/TR/owl-time/, is in OWL-DL. I want to
directly reuse and pref. not split first in a RDFS part and an
OWL-DL part.
Thx for your advice here,
Michel
Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist
T +31888663107
M +31630381220
E [email protected] <mailto:[email protected]>
Location
<https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=%213m1%214b1%214m5%213m4%211s0x47c5b58c52869997:0x56681566be3b8c88%218m2%213d52.000788%214d4.376707>
<image003.gif> <http://www.tno.nl/>
This message may contain information that is not intended for
you. If you are not the addressee or if this message was sent
to you by mistake, you are requested to inform the sender and
delete the message. TNO accepts no liability for the content
of this e-mail, for the manner in which you use it and for
damage of any kind resulting from the risks inherent to the
electronic transmission of messages.
--
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]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
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]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
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]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
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]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
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]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
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].
For more options, visit https://groups.google.com/d/optout.
