search

alps-io / spec

ALPS Specification documents.
59 stars 13 forks source link

Ability to expand a meaning of inherited descriptor vs. overriding keys. #77

Closed fosrias closed 3 years ago

fosrias commented 8 years ago

Currently, the spec indicates that if we create a new descriptor referencing another and define a key in the new descriptor, it replaces the prior. This mechanism can lead to changing fundamental meaning in a strict interpretation.

Need a mechanism to expand. E.g. 

<descriptor id="white">
  <doc>The color white</doc>
</descriptor>

<descriptor id="blanco" href=".../colors/white" />
  <doc>A spanish friendly variant</doc>
</descriptor>

Possibly contrived. But the second doc significantly changes the resulting descriptor by my current interpretation of the spec.

Something we need to think about.

mamund commented 8 years ago

not sure i see a problem here. you mean that the element has been overridden and that's the problem?

On Mon, Oct 19, 2015 at 5:45 PM, Mark W. Foster notifications@github.com wrote:

Currently, the spec indicates that if we create a new descriptor referencing another and define a key in the new descriptor, it replaces the prior. This mechanism can lead to changing fundamental meaning in a strict interpretation.

Need a mechanism to expand. E.g.

The color white A spanish friendly variant

Possibly contrived. But the second doc significantly changes the resulting descriptor by my current interpretation of the spec.

Something we need to think about.

— Reply to this email directly or view it on GitHub https://github.com/alps-io/spec/issues/77.

fosrias commented 8 years ago

Yes. By how I interpret the current spec.

mamund commented 8 years ago

two things.

1) this might be pointing to the difference between "override" (href) and "sameAs" (src). do you mean to actually override id="white" (href) or add an equivalent (src) here?

2) FWIW, i think the doc element is a non-critical element -- at least for machines. i don't expect ppl to write machine code that sets up a dependency on the contents of the "doc" element (but i could be just trying to weasel out of a problem

​

fosrias commented 8 years ago

Well, by my interpretation of the spec, I have overridden the doc. But in this case, I just want to expand on the original descriptor without fundamentally changing its semantic meaning. This later scenario is not afforded in the spec ATM IMO (I have been hanging around you too much using these acronyms).

fosrias commented 8 years ago

Yes, the sameAs working like href, or an array of the URIs is an interesting possibility

fosrias commented 8 years ago

Sorry for the chain, so href is inheritance mechanism and src as an expansion mechanism or something like that.

mamund commented 8 years ago

right - i think this goes back to our thread on the list today.

i'd like to see some kind of "sameAs" pattern and i think it can work along with a single construct - "src" property

http://alps.io/profiles/colors/

a color

http://alps.io/profiles/languages/spanish/

un color

this illustrates reference to a source of the ID, not an override.

just a thought.

​

fosrias commented 3 years ago

@mamund I think we can close this as https://github.com/alps-io/spec/issues/89 could cover this. I think the src argument above works. I am not sure now that expanding the semantic meaning actually means anything 😛 . If something means more, maybe you have changed the meaning. If you want to define broader understanding, but it means the same, src should work.

mamund commented 3 years ago

Closed with a ref to issue #89