Declare which Classes are Stereotypes

[BenjaminHofstetter]

@mchlrch

See also: https://en.wikipedia.org/wiki/Stereotype_(UML)

I would like to be able to declare which classes are stereotypes in order to:

• show them as stereotype markers on a class
• alternatively hide them in the rendering

Example

For example I would like to declare skos:Concept as being a stereotype in the following:

https://spex.zazuko.com/#/?sparqlEndpoint=https://seco-bdb-integ.zazukoians.org/query&forceIntrospection=false&namedGraph&prefixes=admin:https://schema.ld.admin.ch/&prefixes=jolux:http://data.legilux.public.lu/resource/ontology/jolux%23&prefixes=pub:http://publications.europa.eu/resource/authority/language/

Example data sample https://permits.zazukoians.org/professions/220:

the type is https://permits.ld.admin.ch/schema/Profession the stereotype is http://www.w3.org/2004/02/skos/core#Concept

<https://permits.zazukoians.org/professions/220> a <http://www.w3.org/2004/02/skos/core#Concept> , <https://permits.ld.admin.ch/schema/Profession> ;
   <http://www.w3.org/2004/02/skos/core#prefLabel> "dentista"@it , "Dentist"@en , "Zahnarzt/ärztin"@de , "Dentiste"@fr ;   <http://www.w3.org/2004/02/skos/core#notation> "220" ;
   <https://permits.ld.admin.ch/schema/code> 220 ;
   <https://schema.org/position> 2 ;
   <http://www.w3.org/2004/02/skos/core#broader> <https://permits.zazukoians.org/professions/200> ;
   <http://www.w3.org/2004/02/skos/core#inScheme> <https://permits.zazukoians.org/professions/scheme> ;

[BenjaminHofstetter]

If skos:Concept is a stereotype what is the desired output. Right now it's like this.

The problem is that the profession box and the skos:Concept box are the same.

we can remove the skos:Concept box.

Do we have to remove skos:Concept from fields?

[BenjaminHofstetter]

The same is valid for schema:DefinedTerm.

[mchlrch]

The problem is that the profession box and the skos:Concept box are the same.

Exactly, the information shown in both boxes is redundant

we can remove the skos:Concept box.

I would say so, yes.

I have mostly seen and used UML stereotypes to simplify class diagrams. Here's an example taken from http://www.omg.org/cgi-bin/doc?formal/05-07-04

The stereotypes are "Clock" and "Creator". I have mostly seen the presentation option that is shown on the left side.

Do we have to remove skos:Concept from fields?

I would say so, yes.

I think it would be good to validate these assumptions with other concrete datamodels and we should also think about the handling of subclass relationships. The delineation between the handling of this two concerns is not clear to me

[BenjaminHofstetter]

I see a lot of question marks too. "we should also think about the handling of subclass relationships" and sub properties.

what may help in the discussion are we talking about top down or bottom up.

top down (ViewPoints ?):

• We try to document a mode and put all in it what we need.
• Provide the model with the data (ViewPoints, controlled vocabularies and so on )
• check if the data fits the model

bottom up:

• start with data and reverse engineer the model.
• this is more difficult because it depends on inference and are the ontologies in the store or not

"The delineation between the handling of this two concerns is not clear to me" - YES

I suggest to proceed we focus right now on the top down view of this problem. It's less complicated.

[BenjaminHofstetter]

"I think it would be good to validate these assumptions with other concrete datamodels and we should also think about the handling of subclass relationships. The delineation between the handling of this two concerns is not clear to me" @mchlrch

A big YES.

The title of this issue is "Declare which Classes are Stereotypes". Which is a sulution and not a problem. Maybe "Stereotypes" is a way to solve it. I saw the "Composite Structure Diagram" (https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-composite-structure-diagram/).

I would try to focus and what is the problem.

[cristianvasquez]

Maybe what's important to talk about is the metamodel. For example, a meta-model can have UI elements that describe stereotype with markers and looks. Also, each application might declare which classes belong to such UI-element.

A diagram is built using the metamodel.

I think Archimate is a good source of inspiration for metamodels since they have been doing it for years. https://pubs.opengroup.org/architecture/archimate3-doc/chap04.html

This link has use-cases: https://www.hosiaisluoma.fi/blog/archimate-metamodel/

This metamodel encourages analyzing first the WHY question, then HOW, and finally WHAT

[BenjaminHofstetter]

The question is can we reverse these models. e.g right now a schema:DefinedTerm is the UNION of everything that has rdf:type schema:DefinedTerm . That looks like this then.

This should be reduces to what predicates a DefinedTerm really has. The same do we have for SKOS. The irony is that skos:Concept or schema:DefinedTerm are normally "small" with not many predicates. But because it's attached to many instances with many rdf:types they explode with many predicates.

we can try to unwrap this hairball with information from the ontology (domain and range or domainIncludes and rangeIncludes). but this information may not be stored with the data.

The same applies for the class hierarchy. It may be part of the dataset or not. Many times it's not. I suggest we focus on drawing the solution to find out what we want. And then maybe SPEX can implement something.

[cristianvasquez]

I see what you mean; well that diagram shows what the data declares.

You are right drawing a solution first.

To disentangle hairballs is a different problem, that might need some introspection heuristics, for example, count each instance only in their most specialized class and so on, I'm sure there are some heuristics in the wild.