> On 12 Jul 2018, at 10:12, Bohms, H.M. (Michel) <[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]. For more options, visit https://groups.google.com/d/optout.
