Hi @gaurav thanks for the change, I approved

But it would be good to get @hsolbrig's thoughts on this.

There are some deeper questions here about slot identity that we should discuss. It looks like in your case, you are using attributes, which induce a slot name c__s (double underscore). I have sometimes avoided attributes for these aesthetic reasons.

But note also that slot_usage will induce a c_s. For example, I might have a fairly generic slot name that has a range of string, a common description, etc. But I may want one regex pattern to apply for humans, and another for pets. The metamodel creates these different slots under the hood as they have different semantics (minimally).

The question is, how should this be reflected in the end-user oriented markdown?

1. collapse into a single s page, and put any info from c_s on the page for c, under where s is listed
2. have separate pages for each induced slot, but improve their aesthetics in the spirit of this PR
   • for attribute-induced I think it is sufficient just to use name as you do
   • for usage-induced, we may end up with different pages all titled s, so maybe we want to say something like "s in the context of c"?

There is some discussion of this here:

#144

There are some deeper questions here about slot identity that we should discuss. It looks like in your case, you are using attributes, which induce a slot name c__s (double underscore). I have sometimes avoided attributes for these aesthetic reasons.

Actually, I think CCDH needs this name mangling approach: in our model, there is no reason to assume that Specimen.id should have the same definition or constraints as ResearchSubject.id, so the current behavior -- to treat them as entirely different properties -- is correct to me. So maybe it would just be better to include a link to the containing entity in the slot page title?

If we did need a property to be defined identically across multiple classes, we would probably do one of two things:

1. Create a mixin (e.g. Identifiable or HasID) with an id attribute that could be inherited to every class that needed it. We actually used to have an id attribute in our top-level Entity class at one point during development, but that was removed before the v1.0 release.
2. Check to see if an attribute is only defined in a single class. If it is, we can promote it to a top-level slot. If not, we would leave it as a class attribute, but produce a warning suggesting data modelers work on pulling it out into a mixin or eliminate the duplicate property in some other way.

I think in the CCDH case it's still fine though. You would go to the page for "id" to see the very general properties shared by all IDs. This page could also show you how id is used in all different slot_usage concepts. And the individual pages for each class would show id in the context of that class.

Yup, we could do that! I still worry that this might get confusing if we have two identically named fields in two different classes, but since the class-specific definitions will be available on the class pages, it should all be clear. I'll look into that if and when it comes up.