Resolve ambiguity on how to handle attributes

[Silvanoc]

This patch fixes the attributes specification for more clarity on how to handle attributes converting to other formats.

Before this patch the attributes specification had a comment that gave the impression that attributes are only syntactic sugar for class-scoped slots (slots that are only available to be used by a class and its descendants) and specifying the conversion of attributes into slots renaming them to <class-name>__<attribute-name>.

This patch modifies that comment so that attributes are kept as 1st-class-citizens even on conversions.

Fixes: linkml/linkml#3669

[gouttegd]

I am (obviously) not an authority on the meta-model, but FWIW, I agree with this.

The <class_name>__<slot_name> bit is nothing but an implementation detail. This is how some parts of LinkML-Py deal with attributes, but this is not required and there are other ways to deal with them.

[matentzn]

Is it necessary to remove this phrase "Attributes can be specialized via slot_usage."? Seems correct to me..

[gouttegd]

Isn’t that implied by the fact that attributes are “equivalent to slots” – since slots can be specialised via slot_usage?

Though on second thought, at least one generator falsely believes that slot_usage should not be used to refine attributes (linkml/linkml#3438), so maybe keeping that explicit statement would in fact be helpful…

[Silvanoc]

I don't remember if I removed it for a specific reason or it was just an erroneous "delete until end of line". I'll double check.

[Silvanoc]

Perhaps a rewording like

Attributes are slots and such can be also modified via slot_usage.

might be helpful here. Assuming that it's true, what I still have to double check.

[gouttegd]

Assuming that it's true, what I still have to double check.

But the question is, where do you check that? AFAIK, the only place in the meta-model where anything is said about slot_usage applying to attributes is here. The definition of slot_usage only says that it is “the refinement of a slot in the context of the containing class definition” – which may be interpreted as being applicable to attributes given that an attribute is nothing more than a type of slot, but who knows?

The “reference implementation” (LinkML-Py) is not helpful here since its different components cannot agree with each other. SchemaView is of the position that slot_usage does apply to attributes. But the Python generator (which is not based on SchemaView) disagrees.

[matentzn]

Does it make sense to change that here as well?

linkml-model/linkml_model/model/docs/specification/03schemas.md

Line 174 in 35c91fb

| [attributes](../attributes.md) | 0..* <br/> [SlotDefinition](../SlotDefinition.md) | Inline definition of slots |

[matentzn]

What would you expect child_via_attr to come out as here?

slots:
  parent_slot: {abstract: true, required: true, pattern: "^x.*", multivalued: true}
  child_via_slot: {is_a: parent_slot}
classes:
  ViaSlots:
    slots: [child_via_slot]
  ViaAttrs:
    attributes:
      child_via_attr: {is_a: parent_slot}

Same parent, same is_a. child_via_slot comes out required, patterned and multivalued; child_via_attr comes out with none of them — and per the spec that's correct, not a bug. Still "equivalent"?

[Silvanoc]

I would expect child_via_slot and child_via_attr to have exactly the same attributes.

I don't know if this comes from the descendants part. If that's the case, it refers to the class declaring the attribute and its subclasses. It has nothing to do with a slot's is_a relationship.