It is a matter of the design choices. In either case cmo:hasDirectPart would be a property.
Aspects are most useful when they are used to group multiple properties as a block, not a single property. Then, they are used as parent classes - kind of an alternative inheritance structure. Overall, this topic is too complex to discuss in e-mails. > On Jul 12, 2018, at 9:33 AM, Bohms, H.M. (Michel) <[email protected]> wrote: > > 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] > 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: 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]> 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. > > -- > 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.
