Descriptors for Enumeration Members

[dillonredding]

Should the schema.org's enumeration members have their own descriptors nested under the corresponding enumeration? For example, for DayOfWeek:

<alps>
  <descriptor id="DayOfWeek" type="semantic" href="http://alps.io/schema.org/Enumeration#Enumeration">
    <doc href="https://schema.org/DayOfWeek" />
    <descriptor id="Monday" type="semantic">
      <doc href="http://purl.org/goodrelations/v1#Monday" />
    </descriptor>
    <descriptor id="Tuesday" type="semantic">
      <doc href="http://purl.org/goodrelations/v1#Tuesday" />
    </descriptor>
    <descriptor id="Wednesday" type="semantic">
      <doc href="http://purl.org/goodrelations/v1#Wednesday" />
    </descriptor>
    <descriptor id="Thursday" type="semantic">
      <doc href="http://purl.org/goodrelations/v1#Thursday" />
    </descriptor>
    <descriptor id="Friday" type="semantic">
      <doc href="http://purl.org/goodrelations/v1#Friday" />
    </descriptor>
    <descriptor id="Saturday" type="semantic">
      <doc href="http://purl.org/goodrelations/v1#Saturday" />
    </descriptor>
    <descriptor id="Sunday" type="semantic">
      <doc href="http://purl.org/goodrelations/v1#Sunday" />
    </descriptor>
    <descriptor id="PublicHolidays" type="semantic">
      <doc href="http://purl.org/goodrelations/v1#PublicHolidays" />
    </descriptor>
  </descriptor>
</alps>

P.S. Sorry for bombarding this repo lately :) Been looking to recommend the official ALPS registry for use at work, which forced me to take a very close look at everything.

[mamund]

sure -- you can do that.

i usually resolve lists memberships at runtime in the request response. that way i can control the enumerations locally and not be worried that i need to come up w/ a definitive list of all the possible value for all the possible uses for all the possible people in all the possible security contexts that will ever use this interface into the future.

but, for fixed elements like your example, it makes sense.

[dillonredding]

That's totally fair. Do you think the registry should update some/all enumerations or remain as-is?

[mamund]

the ALPS documents in this folder should -- above all -- be consistent. just like any other interface design.

i'll confess i'm concerned that breaking changes are possible here and that might harm some current users. but, frankly, i don't know that anyone is actively using them, so...

at some point, major deviations from the original publication need to become a fork so that some can continue to enjoy the new features w/o messing up any existing users' work.

[dillonredding]

the ALPS documents in this folder should -- above all -- be consistent. just like any other interface design.

... i don't know that anyone is actively using them

Agreed. I'd be curious if anyone is using it since the links are broken. If they are, they aren't using it according to the specification. Personally, I'd say that's fair game to make "breaking fixes".

[mamund]

i'm OK w/ the changes you're discussing here. I'd post to the google groups just to make sure.

and, eventually, we'll need to start some for of explicit versioning to allow for growth w/o breakage on these vocabularies. @fosdev / @fosrias and I had been talking about that a while back. he may have some suggestions on a versioning governance pattern we can adopt.