Re: update on Exit Criteria, was Re: ORG futures

On 2013-04-16, at 5:48 PM, Dave Reynolds wrote:

> In trying to figure how to approach CR I've been thinking of ORG as a simple core (the notion of an organization, minimal properties for describing and classifying one, simple membership properties) plus a set of "features". These are:
>  1. sites and addresses
>  2. organizational substructure
>  3. posts
>  4. roles and the org:Membership n-ary relation
>  5. historical information
>  6. collaborations
> 
> Each "feature" is a bundle of classes, properties and the occasional axiom.
> 
> The early ones are used a lot. It's less clear how much the later ones have been used to date.
> 
> The thing I'm mulling over is that if no one during CR touches a feature at all, say historical information, then we might worry it has not had sufficient work out to be sure it is fit for purpose. Whereas if they touch a feature but don't use every corner if it then that's fine.

In my own work and efforts to get ORG adopted, 2, 3 and 4 are used extensively. So far, 6 has never come up.

For 1, it's often easier to just leave addresses as a blob of text, and not worry about splitting it into component parts. The use cases that I encounter need to associate an address to a person/post, not an organization; in those cases, it's easier to have a direct relation between a person/post and an address instead of going through a Site, since we rarely have any additional info to attach to the site. It's a bit too indirect to mint a new site just to attach an elected officials constituency address to that site. So, that bundle isn't being used much in my work.

For 5, org:memberDuring is the only property in that bundle, as far as I know. ORG has no support for historical posts or historical organizations. (Schema.org has foundingDate for an Organization, but no dissolutionDate. It also has birthDate and deathDate for people.) It's impossible in ORG to express the date on which a person started holding a post, or to express a post previously held by a person; in my work (which is mostly JSON), I allow a membership to refer to a post in order to achieve these. In those use cases, the post never refers to the person holding the post; that's left up to the memberships, present and past.

All that to say, I wouldn't consider 5 to be a fleshed-out bundle. I certainty haven't been reviewing ORG as if that were one of its features. I'm happy to keep org:memberDuring around, but I wouldn't feel comfortable saying that ORG is any good at expressing historical info.

James