Responding to just the part about inverse properties. I remember reading a post from Tim Berners Lee a few years back where he argued that inverse properties should never be used and using them was a bad practice. Because one can always interpret a triple in inverse, there is no need for inverses and they do more harm than good. If the problem is how to name the inverse direction, a property could be annotated with the inverse name. I can’t locate this post any more.
Traversing links in inverse should not be a problem for any UI. At least, it is a by far a much smaller problem than maintaining integrity of the inverse statements in the presence of changing data. In my experience, such thing is always to be avoided in software development, especially when simpler, less error prone and more elegant approaches are available. And the work needed to enable software to traverse links in opposite direction also pales in comparison to the complexity of having the software be able to understand all the different ways a model can express the same or nearly the same information (with some subtle differences understood only by very few). As the ‘last resort’ inverses could be generated when data is exported/transformed for use by the limited UI (provided, it is read only). I believe care needs to be taken with this approach since the mere presence of inverse properties in a model often causes confusion - which ones do I use when I create data? I think, at minimum, the inverse properties should be annotated with the information about them being just for ‘caching’. Or, better, kept separate and only added when provided to the read only UI or system that can’t function without them. Thus, my advice for situations when one is developing models (or a group of people working together are developing models) has always been and continues to be to avoid, if at all possible, the use inverses. When reusing models or integrating models/data from different communities, there may be another reason for inverses. One may needed to say some additional things about a relationship and it is most convenient to be stated in the direction that is different from property’s direction. SHACL addresses this by providing inverse property paths. Of course, in a more general sense reuse and integration are broader and more complex topics. In reality, handling differences often requires some data transformation, anyhow. Sent from my iPhone > On Jul 6, 2018, at 6:16 AM, David Price <[email protected]> wrote: > > > >> On 6 Jul 2018, at 02:41, Holger Knublauch <[email protected]> wrote: >> >> >> >> 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. > > That’s strictly true for RDF and SPARQL. However, many user interfaces that > support a UI-only search or mapping capability, only support handling a > forward reference. That is why we have customers now that use OWL inverses > extensively. Otherwise, it’s very hard for the end user to get from Instance1 > to Instance2 and also from Instance2 to Instance1 in the UI navigation. We > have no idea if such a UI will be required in the user community, and that > raises a meta-level concern for me as follows: > > It’s not clear what the usage scenarios or use cases are, who the actual > customers are, etc. Everyone has different perspectives on this topic (e.g. > Holger prefers only SHACL and I prefer having every tool available in my > modelling tool box) and so IMO trying to select precisely what subset of > RDFS, OWL, and SHACL should be in a modelling guide is not a sensible thing > to do via a forum like this with so little understanding of the actual > problem. > > If I’m a typical SemWeb/Linked Data modeler today, got involved in Michel's > project and was told to throw away most of what I’ve ever used I’d really > wonder how that guide was developed and upon what deep understanding of the > problem it was based. Michel does not have a good response to that since > there was no deep analysis done. Also - seems like this all may just be the > result of a vast over-reaction to the limited set of problems wrt OWA, for > which there are nice solutions available in a layer of SHACL, and Michel may > be throwing away a lot of baby with the bath water. > > Michel - IMO something like this should really be a more like a 3 day > workshop with your ontologists and SMEs to understand what you need and *only > then* provide such detailed advice. > > Cheers, > David > >> >> 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] >>> 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 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] >>> 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 Irene Polikoff >>> Sent: woensdag 4 juli 2018 18:10 >>> To: [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]> >>> 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. >>> -- >>> 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.
