Thx David for the extra views/warnings. All clear. What I COULD do on the safe side as alternative: just define an rdf:Property cmo:hasDirectPart in CMO
And then state in guide how to use this property in shapes for rdfs domain classes In that case I have no floating classes that have to be subclassed (ie no overhead). Would that make sense? 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=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.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] <[email protected]> On Behalf Of David Price Sent: donderdag 12 juli 2018 13:56 To: [email protected] Subject: Re: [topbraid-users] SHACL usage On 12 Jul 2018, at 10:12, Bohms, H.M. (Michel) <[email protected]<mailto:[email protected]>> wrote: 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 ; ] . Take care wrt using Aspects for a data exchange ontology. It’s a fine approach when you are making a specific app against which you create code implementing specific features. It’s a bit confusing when defining data requirements because you end up with a lot of optional properties and little or no guidance about which ones are to be used in a specific exchange. You sometimes end up with a Class having several superclasses, which is also confusing to folks reading documentation who have to chase over a large PDF to figure what the complete set of properties for that subclass actually are (try reading the OMG UML spec). FWIW UML specifications used Aspects in some cases - e.g. NamedElement, PackageableElement and ParameterableElement and then inside the UML tools everything you create (e.g a class) has tons of options to set (e.g. visibility). In EDG Identifyable and Narratable (i.e. typically name, ID and definition) results in 10 total properties, all optional, which is lot of nice capability but may be too open wrt a data exchange specification. In your example, what is the value of Composable class that say PhysicalAsset is a subClassOf vs just having PhysicalAsset allow hasDirectPart relaton to other PhysicalAssets? Note that you’d probably need to specify that extra constraint in PhysicalAsset anyway to make sure it does not, for example hasDirectPart a Person. In ISO 15926 the equivalent of Composable is called ArrangedIndividual and is in the “upper" part of the ontology making it clear that only Individuals can have parts (i.e. Classes cannot have parts). If you just have Composable "floating in space", then others may subclass it inappropriately. Again, not saying Aspects cannot be useful … just take care. Cheers, David -- 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.
