Incorrect Descriptor Types?

[dillonredding]

I'm wondering if the descriptors for schema.org schemas have the "correct" type. Seems that if the data type is a URL, then it's safe. Otherwise, it's semantic. That works for some media types (e.g., JSON or XML), but feels less desirable for more hypermedia-focused formats (e.g., HAL or Siren).

Should schema properties instead be defined as follows?

• If a property can be a basic Data Type (except URL), it's a semantic descriptor.
• If a property can be a URL, it's a safe descriptor.
• If a property can be another schema, it's a safe descriptor with an rt of that schema (URL points to registry).
• If a property is both a semantic and safe descriptor, there should be two descriptors with the same name but different ids. The latter can inherit the former via href.

<descriptor id="Product" type="semantic" href="http://alps.io/schema.org/Thing#Thing">
  <!-- ... -->
  <descriptor id="gtin" type="semantic">
    <doc href="https://schema.org/gtin" />
  </descriptor>
  <!-- ... -->
  <descriptor id="manufacturer" type="safe" rt="http://alps.io/schema.org/Manufacturer#Manufacturer">
    <doc href="https://schema.org/manufacturer" />
  </descriptor>
  <!-- ... -->
  <descriptor id="model" name="model" type="semantic">
    <doc href="https://schema.org/model" />
  </descriptor>
  <descriptor id="modelLink" type="safe" href="#model" rt="http://alps.io/schema.org/ProductModel#ProductModel" />
  <!-- ... -->
  <!-- What happens if property can be a URL or another schema? -->
  <descriptor id="logo" name="logo" type="safe">
    <doc href="https://schema.org/logo" />
  </descriptor>
  <descriptor id="logoLink" type="safe" href="#logo" rt="http://alps.io/schema.org/ImageObject#ImageObject" />
  <!-- ... -->
</descriptor>

[mamund]

there are lots of challenges in translating other vocabulary outputs to ALPS.

it's the last on your list that gave @leonardr and i a challenge. i usually have two descriptors w/o any nesting. they share the same name and have unique id values.

as an aside here...

there is rarely a single correct way to express an intent. and ALPS is designed to allow ppl to come up w/ ways to express vocabularies in ways that work for them (and not necessarily that work for everyone).

i am committed to keeping ALPS loose enough to allow people to create solutions that they need and expect that, with this kind of approach, the more useful solutions will become more often-used -- all based on users' decisions, not mine (or anyone else managing the spec).

[dillonredding]

_there is rarely a single correct way to express an intent_...

At work, my team and I ran into this. We tried offering general purpose JSON Schemas that modeled the schema.org vocabulary and eventually came to the conclusion that those a very different uses of the term "schema". Some people only needed subsets of certain schemas, and others needed different constraints on certain properties, so it just ended up creating a lot of bloat.

I definitely see the benefit of keeping ALPS loose, I just wasn't exactly sure where the official registry should land on this. From the spec:

When 'descriptor' has a property defined locally, that property value takes precedence over any inherited property value.

I suppose, worst case scenario, you could simply override the type in your own ALPS document:

<descriptor id="model" type="safe" href="http://alps.io/schema.org/Product#model" />

[mamund]

yeah - this override situation is a great example of the perils of using inheritance in your designs. the fact that you can't see the results of the inheritance very easily is just adding more bad mojo to the concept.

add to that using inheritance in a world where you don't control all the participants (e.g. the WWW) and all sorts of unintended breakage is bound to occur.

my approach so far has been to focus on solving the problem locally and making loose references (via my src and ref extensions) to other related descriptions.

that has done me just fine so far.