Select inverse properties

[azaroth42]

In particular, after discussion with @awoods we think it's important to capture inverse properties for:

• [x] foaf:member
• [x] foaf:account

Proposal to use org:memberOf for inverse of foaf:member. Note that org:memberOf is inverse of org:member is equivalent property to foaf:member. This is a recent TR from W3C.

Proposal to use sioc:account_of for inverse of foaf:account. It's explicitly that :)

:+1:s?

[mjgiarlo]

:+1:

[no-reply]

Note: Inverse properties are needed because of the nature of the knowledge needed at various points in the authorization process.

When signing on, we will know the account before we know the user/Agent, so it's important to link in that direction.

Similarly, when authorizing against a Group, the ACL Authorization will know which groups it allows and the Agent requesting, but not necessarily the full list of Group membership. It's more efficient to check the user's groups than to scan membership of allowed group.

[no-reply]

Note that soic:account_of specifies a range of soic:UserAccount. This is a subclass of foaf:OnlineAccount. Given the inverseProperty statement, it must also be formally an equivalentClass but there's a little bit of modeling oddity in the expression.

I don't think it's a problem, either in theory or in practice; so :+1: on using it. We should be a little careful about using other parts of the soic model, given this weird usage.

[azaroth42]

Yup, agreed. I think we're good on this topic?

[no-reply]

org:memberOf seems really straight forward. No reservations on the :+1: there.

Yup, agreed. I think we're good on this topic?

:shipit: