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]> 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] > Location > > > <image001.gif> > 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 David Price > Sent: woensdag 4 juli 2018 17:18 > To: [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]> 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] > Location > > > <image001.gif> > 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 Richard Cyganiak > Sent: woensdag 4 juli 2018 12:14 > To: [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]> 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] > Location > > > <image001.gif> > 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]. > 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. > -- > 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. > -- > 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. > -- > 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. -- 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.
