How to reference semantic descriptors with hierarchical structures

[koriym]

ALPS documents use semantic descriptors to define the meaning of words, but these words can be what the user intends them to be, depending on what they are included in.

For example, name is defined as "The name of the item." in schema.org. But the name is the name of a person if it is included in "person", or the name of a product if it is included in "product". Thus, the exact meaning of a phrase depends on the combination of what it belongs to.

See ALPS document.

{
    "$schema": "https://alps-io.github.io/schemas/alps.json",
    "alps": {
        "descriptor": [
            {"id": "name", "def": "https://schema.org/name"},
            {"id": "product", "descriptor":[{"href": "#name"}]}
            {"id": "person", "descriptor":[{"href": "#name"}]}
        ]
    }
}

ALPS allows you to define the position of those hierarchical words, but what if you want to use those words outside of ALPS?

For example, HTML forms cannot have such hierarchical meanings. Instead of a hierarchy, you would have a flat structure like this

<form>
    <input name="productName" type="text">
    <input name="personName" type="text">
</form>

Or how to express those context-sensitive words in a plain English sentence?

Example.

"The order requires product.name and person.name."

or

"The order requires product/name and person/name."

Is there a better way to describe a word when you want to deliberately reference a word used in ALPS, rather than just using ordinary English as a "product name"?

I thought it would be good if there was an ALPS recommended expression to answer these questions.

[mamund]

yes. this is something to explore. right now (after scanning my own content) i find that media-type specific solutions (e.g. JSONPath and XMLPath) are what i rely upon to deal with hierarchies at runtime. for example, reading ALPS and producing OpenAPI.

but we have no general, universal way of talking about nesting/hierarchies in ALPS right now.

one way to approach this is to focus on how we are all solving problems like this in real life and see if we can come up w/ best/common/recommended practices for using ALPS in general.

to that end, as we discussed online in the chat, I created a new repo: https://github.com/alps-io/best-practices where @koriym is now going to help us all put together some recommendations and practices.

i encourage everyone to chime in w/ examples of how the use ALPS and how we can help others take advantage of ALPS features.

along the way, we can address is very point -- "how do you deal with hierarchies within ALPS documents?"

-- @mamund