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

[fosrias]

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]

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
#77.

[fosrias]

Yes. By how I interpret the current spec.

[mamund]

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]

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]

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

[fosrias]

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

[mamund]

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/ <descriptor id="white"> <doc>a color</doc> </descriptor> http://alps.io/profiles/languages/spanish/ <descriptor id="blanco" src="http://alps.io/profiles/colors/#white"> <doc>un color</doc> </descriptor> this illustrates reference to a source of the ID, not an override. just a thought. ​

[fosrias]

@mamund I think we can close this as #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]

Closed with a ref to issue #89