sh:in is closed vs sh:hasValue is open

Hi folks!

There's a semantic distinction between sh:in and sh:hasValue that
escaped me until recently:
sh:in is closed (all values must be in the list) vs sh:hasValue is open
(there can be extra uncontrolled values).

1. The Ontotext Platform basically works over open-ended RDF data,
  i.e. the platform schema imposes some control over nodes, but there can
be extra uncontrolled values.
  (We may in the future start using sh:closed and sh:ignoredProperties).
  Our "semantic type discrimination" allows value lists, so currently
Havard generates
  sh:or([sh:path; sh:hasValue]...) where the path is repeated many times.

2. So we're thinking of adding an open-ended version of "in": dash:valueIn.
 What do you think?

3. There's still something that puzzles me about sh:in :

ex:StanfordOrYaleGraduate a sh:NodeShape ;
  sh:property [sh:path ex:alumniOf; sh:in (ex:Stanford ex:Yale)] .

Havard asked and Irene confirmed this wouldn’t work in the case that
someone graduated from both ex:Stanford and ex:Harvard.
Why? Both of the values are in the list, so the shape should succeed?

4. Finally, can I combine "in" with "ignoredProperties" to request at least
one value in the list but allow extra value?

ex:StanfordOrYaleGraduate a sh:NodeShape ;
  sh:ignoredProperties (ex:alumniOf);
  sh:property [sh:path ex:alumniOf; sh:in (ex:Stanford ex:Yale)] .

-- 
Vladimir Alexiev, PhD, PMP
Chief Data Architect
Sirma AI, trading as Ontotext: https://www.ontotext.com, LinkedIn
<https://www.linkedin.com/company-beta/208070>, Twitter
<https://twitter.com/ontotext>, Rate GraphDB
<http://www.capterra.com/database-management-software/reviews/157533/Graph%20DB/Ontotext/new>
Email: vladimir.alexiev@ontotext.com, skype:valexiev1
Mobile: +359 888 568 132, SMS: 359888568132@sms.mtel.net
Calendar:
https://www.google.com/calendar/embed?src=vladimir.alexiev@ontotext.com
Publications and CV: https://github.com/VladimirAlexiev/my