On 12/07/2018 18:34, Bohms, H.M. (Michel) wrote:
seeAlso: ok, kept
domain class: ok but how to provide it as a generic resource (for others to
attach to their domain classes). In current CMO I provide simply a global
owl:DatatypeProperty. How can I provide a local shacl property in a global way?
Of course I can always put in my guide: “attach a shacle property with that
name…etc.” but hoped to be able to be more explicit….
I can see that you always need some context for the shacle property so I
thought maybe add it to an existing root-like entity so that all my instances
of rdfs:Class get it automaitically as relevant property
Is the value range (sh:class) of this property always the same? It doesn't
sound like it. Then you should redefine local constraints to narrow it down the
respective local value type.
> typically they are always different… (making up the “typcal decomposition
> hierarchy” or meronomy). So indeed this one (sh:class) should always be
> “modelled” anyway. I just want to make sure somehow that the unconstraint
> local property is always the same….
SHACL has a syntax for global constraints, using sh:targetSubjectsOf and
sh:targetObjectsOf. You'd define something like
ex:PartOfShape
a sh:NodeShape ;
sh:targetSubjectsOf ex:hasPart ;
sh:property [
sh:path ex:hasPart ;
sh:class ...
] .
> ok but then I have my own root ‘PartOfShape’ that I prefer not to define….and
> it feels more postprocessing after people used the right decomposition
> property…
and the shape would apply to all subjects that have any value for hasPart.
However, tool support for this is a bit inconsistent right now, so if you just
want to offer a reusable building block, wrap it into a class shape and tell
your users to use multiple inheritance:
ex:Composable
a sh:NodeShape, rdfs:Class ;
sh:property [
sh:path ex:hasPart ;
sh:class ...
] .
> again but now with my own root Composable
ex:MyClass
rdfs:subClassOf ex:Composable ;
rdfs:subClassOf ...
If you are familiar with the EDG ontologies, this is a recurring pattern:
wrapping reusable building blocks into abstract base classes such as
edg:Identifiable, edg:Locatable (note the "able"). These are sometimes called
aspects.
> interesting….would be good to somehow have some standardized/authorative list
> of those. That would solve the issue…. Guess the one I need that way is a
> standard “Decomposable” (ie something that can have parts). Think I use for
> the moment cmo:Decomposable as placeholder and tell in guide to make relevant
> domain root classes a subclass of it (some overhead price to pay) and add the
> specific ranges per such domain class.
* cmo:Composable
a sh:NodeShape, rdfs:Class ;
sh:property [
sh:path ex:hasDirectPart ;
] .
THX! Michel
Holger
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>
[cid:[email protected]]<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 Holger Knublauch
Sent: donderdag 12 juli 2018 10:25
To: [email protected]<mailto:[email protected]>
Subject: Re: [topbraid-users] SHACL usage
On 12/07/2018 17:49, Bohms, H.M. (Michel) wrote:
Thx Holger,
Changed indeed float>decimal.
Two more small issues.
- best way to refer to non-LD: now via rdfs:seeAlso (ok or otherwise?)
Yes.
- in case I replace my cmo owl-decomposition by shacl, what is the best entity
to attach it too (ie what is best XY below)? I prefer not to introduce some own
root for simplicity. owlThing? rdfs:Resource? I have to put it somewhere, right?
This should be attached to the "domain" class, where you want to see the values
on the forms. Given that you want the inverse direction, the domain class would
be the "range" class of cmo:hasDirectPart, whatever that is. If it's a generic
property that is used in multiple places, maybe introduce multiple such local
constraints.
Holger
thx
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>
[cid:[email protected]]<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 Holger Knublauch
Sent: vrijdag 6 juli 2018 03:42
To: [email protected]<mailto:[email protected]>
Subject: Re: [topbraid-users] SHACL usage
On 6/07/2018 4:41, Bohms, H.M. (Michel) wrote:
Thanks Richard, Irene, David & Holger for all your advice here!
For our modelling guide I now start with:
Serialisation: Turtle
CMO (advice on any more generic variants welcome)
* cmo:hasDirectPart
* cmo:isDirectPartOf
* ! currently using in here owl:inverseOf, guess I better use shacl here
too (?)
My personal opinion is to avoid inverse properties and owl:inverseOf in
particular. The problem is redundancy: you need two distinct triples for the
same information. RDF triples can be walked both ways - from subject to object
or from object to subject and languages like SPARQL make this easy. So there is
no real reason to have two properties for both directions, and in fact they can
make working with such data harder.
In SHACL you could replace cmo:isDirectPartOf with
XY
sh:property [
sh:path [ sh:inversePath cmo:hasDirectPart ] ;
sh:name "is direct part of" ;
...
]
and form generators and features like GraphQL would still understand what you
mean, and would present information accordingly.
*
CDT
* QuantityKinds as rdfs:Datatype from
https://ci.mines-stetienne.fr/lindt/v2/custom_datatypes.html#mass
* Turtle: https://ci.mines-stetienne.fr/lindt/v2/custom_datatypes.ttl
* Units in WKT-string from http://unitsofmeasure.org/ucum.html
SHACL (full)
OWL
* owl:Ontology (@holger: guess this one is the only second owl construct
needed)
Yeah, sometimes we use this to identify the graph itself, but it's technically
not really necessary. No harm though.
*
* owl:imports
* maybe owl:versionInfo (but proab. Not need when already in URI strategy…)
RDFS
* rdfs:Class
* rdfs:Datatype (@holger: I need this one for use of CDT quantityKinds)
* rdfs:subClassOf
* rdfs:label
* rdfs:comment
RDF
* rdf:Property
* rdf:type
XSD
* xsd:string
* xsd:float
* xsd:integer
* xsd:Boolean
Looks good (except xsd:boolean is lower-case and I typically use xsd:decimal
over xsd:float because of unlimited precision that xsd:decimal offers).
Holger
*
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>
[cid:[email protected]]<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 Holger Knublauch
Sent: donderdag 5 juli 2018 01:07
To: [email protected]<mailto:[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>
[cid:[email protected]]<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 in http://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
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.
--
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].
For more options, visit https://groups.google.com/d/optout.
