inScopeOf range
Early in the project we decided that inScopeOf would have a rdfs:range of owl:Thing, to leave it completely flexible. In the earlier software (NRP etc.) we had a range of Agent. Some of the discussion in VF was that geographic areas, projects that don't rise to thinking of themselves as an agent, looser networks, might want to be a scope.
My thinking is that we would do better closing it off to just Agent, which I think we can define rather loosely, as it doesn't take much governance for a group to have some agency. I think inScopeOf should apply only to things that people want to do some accounting for, usually ongoing. If people want to do accounting, I think it is pretty sure to be an Agent. If they are more ad-hoc, summarization of data can be done by filtering instead of defining a thing, and no scope is needed. For example, this might apply to summarizing data within a non-agent geographic boundary.
I'm also going to copy some discussion from the holochain forum here that disagrees with my opinion. From yeff (don't know github name):
If I may give my opinion on the value type of “inScopeOf”, then I would say that I’m in favour as well to open it up and not limit it to “Agent”. Let’s say we want to have the option to use either “Agent” or “uri”. In UML this can be solved via assigning a value type that is the union of both “Agent” and “uri”. This can be modelled as well in the ontology using the union on the range and in the JSON-schema with a “one of” construct (I think).
Although I prefer just Agent, I would be OK with the union of Agent and uri as the range. Or adding on other specifically defined classes that people think might rise to the level of wanting some accounting. I think owl:Thing is way too broad semantically, and leaves the use of inScopeOf unclear, although it was handy to have a flexible decision before some of VF was defined. And I don't think we want Thing as something part of the VF model, for example in the json-schemas. Even if uri can be used for anything.
I looked, and "oneOf" indeed seems like it can be used in the json-schema definition, good to know, and I can fix based on this decision.
Other opinions? If there is some agreement, I'll do a PR.