*
Comments still very welcome! 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]
<[email protected]> *On Behalf Of *Holger Knublauch
*Sent:* donderdag 5 juli 2018 01:07
*To:* [email protected]
*Subject:* Re: [topbraid-users] SHACL usage
In my own work, I no longer use anything from the OWL namespace except
owl:imports. However, some people start they class hierarchies at
owl:Thing basically to distinguish "domain" classes from "system"
classes. But that's an arbitrary distinction and thus problematic too.
owl:DatatypeProperty and owl:ObjectProperty are not really needed and
don't add value except hypothetical backwards compatibility with tools
that only understand OWL and not RDF.
Your list below on selected resources from RDF/S namespaces is what I
use as well. rdfs:subClassOf is very important and is even used
officially in the SHACL spec. rdfs:label and comment are
well-established. I am typically not using rdfs:subPropertyOf because
this takes us on a slippery slope of requiring inferences (walking the
subclass hierarchy is simply unavoidable, while putting subproperties
into a hierarchy is often over-used to categorize properties, and for
that there are better alternatives). In general, SHACL has no notion
of properties as stand-alone entities, i.e. you don't even need to
define an rdf:type for the properties.
Holger
On 5/07/2018 7:22, Bohms, H.M. (Michel) wrote:
Hi Irene
Ok , but would there be any extra benefit (beyond just
rdf:property) when not OWL-inferencing?
Ie why would I introduce only those from owl when cwa/shacl modelling?
(just playing devils advocate)
Thx 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]>
<[email protected]>
<mailto:[email protected]> *On Behalf Of *Irene Polikoff
*Sent:* woensdag 4 juli 2018 18:10
*To:* [email protected]
<mailto:[email protected]>
*Subject:* Re: [topbraid-users] SHACL usage
I do not see much harm in having owl:DatatypeProperty and
owl:ObjectProperty. Most modeling languages differentiate between
attributes and relationships.
Of course, with SHACL this is not really needed, but may be useful
as an annotation.
Sent from my iPhone
On Jul 4, 2018, at 11:40 AM, Bohms, H.M. (Michel)
<[email protected] <mailto:[email protected]>> wrote:
Hi David,
Some background (vcon/interlink – like).
We have a use case where data is exchanged between a client
(infra asset manager) and a contractor say about a road
section or bridge.
They have to use the same ontology in the middle but both
parties might have more detailed restrictions to which they
want to validate. So we have both data sharing and data
validation.
(note there will be a n x m relationship between client &
contractors).
We have to convince them linked data is feasible (beyond
relational) so we have to keep things as simple as possible at
least as CWA as possible. They are scary about OWA…
With the below I was investigating how simple I can go. Seems
like in the middle (sharing):
RDFS
- rdfs:Class
- rdfs:Datatype
- rdfs:subClassOf
- rdfs:label / rdfs:comment
RDF
- rdf:Property
- rdf:Datatype
- rdf:type
XSD
- xsd:string
- xsd:float
- xsd:integer
- xsd:boolean
And on the sides (validation): full shacl.
In the middle we then define/agree things like Bridge,
TrafficBarrier etc as rdfs classes and designLifeExpectancy as
rdf properties (ie no complex ‘objectfications). We only add
in facilities for:
- decomposition (hasDirectpartOf), that can be constrained
(CWA) on class level, and
- quantities & unit (CDT units) where quantities (better:
quantityKinds) are modelled as datatypes and the units in WKT
like “230 mm”
That’s seems a nice compromise between power and simplicty in
this case….(especially the transformations that is format
translators and semantics convertors to and from their native
applications (typically relational) stay simple enough too…
(round trip data client <> contractor involving
syntax/semantics via some middle takes 8 transformations
now…so in parallel we will promote sharing iso conversion…..).
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>
<image001.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.
*From:*[email protected]
<mailto:[email protected]>
<[email protected]
<mailto:[email protected]>> *On Behalf Of *David
Price
*Sent:* woensdag 4 juli 2018 17:18
*To:* [email protected]
<mailto:[email protected]>
*Subject:* Re: [topbraid-users] SHACL usage
Hi Michel
I would say you’ve not given enough background for a clear answer.
Background items like these could change the answer :
Are you sharing with others? If so, what tools do they have?
Are you implementing an app? If not what or who is the customer?
Are you defining something to be taken and extended by others?
Where is source of any data? Does it have a data model? Is it
a fixed or growing set of data, or does it not exist yet?
For example, if your data is fully specified wrt data type and
type and is complete and a good existing app generates it and
you are just harvesting it for linking, for example, then OWA
concerns are less important.
Just a few thoughts to consider.
Cheers,
David
On 4 Jul 2018, at 11:54, Bohms, H.M. (Michel)
<[email protected] <mailto:[email protected]>> wrote:
Thx!
So, to be sure (100-harmless), I could use even a subset
of RDFS (“RDFS-“) without domain & range for sharing the
vocabulary.
Domain and range can come in at SHACL.
‘RDFS-‘ would then be simply:
- rdfs:Class
- rdfs:Property
- rdfs:Datatype
- rdfs:subClassOf
- rdfs:subPropertyOf
- meta-stuff like: rdfs:label / rdfs:comment /rdfs:seeAlso
/ rdfs:isDefinedBy
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>
<image001.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.
*From:*[email protected]
<mailto:[email protected]>
<[email protected]
<mailto:[email protected]>> *On Behalf Of
*Richard Cyganiak
*Sent:* woensdag 4 juli 2018 12:14
*To:* [email protected]
<mailto:[email protected]>
*Subject:* Re: [topbraid-users] SHACL usage
My subjective answer:
RDFS has OWA semantics, but RDFS has so little
expressivity that it’s OW-ness doesn’t really become a
problem. So I would consider the inclusion of RDFS
definitions “mostly harmless”. Especially rdfs:subClassOf
is fine. I find rdfs:domain and rdfs:range more
problematic, but that’s not because of OWA per se, but
because their semantics is not what most people expect.
Richard
On 4 Jul 2018, at 08:01, Bohms, H.M. (Michel)
<[email protected] <mailto:[email protected]>> wrote:
In case the purpose of modelling is really‘data
validation’would it be better to go for SHACL-only (ie
CWA-only) or still combine SHACL with RDFS?
(like inhttp://spinrdf.org/shacl-and-owl.html). Would
there be a downside of a SHACL-only approach. Like
always having to specify properties in the context of
a shape?
In case of validation AND data sharing would it still
work or would it be better to use‘RDFS + SHACL’where
the SHACL is separately used at say 2 validation sides
(importing the RDFS) and RDFS-only for the sharing spec?
But then introducing some potential OWA/inference in
the middle (that doesn’t HAVE to be utilized). Or is
all THAT inference harmless wrt OWA/CWA discussion (ie
inferencing rdfs superclass instantiation).
Thx for your views 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>
<image001.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
[email protected]
<mailto:[email protected]>.
For more options, visithttps://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]
<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.
