On Jul 30, 2014 7:57 AM, "Eric Prud'hommeaux" <eric@w3.org> wrote: > Why do we neet to attach it to a type? Wouldn't that mean that every reusable object would have to have a bunch of types attempting to predict all of the ways that data might be used? For instance, wouldcthe admitting physician need to have type arcs asserting that he/she was a bethIsreal:SurgicalPhysician, bethIsreal:EDAdmittingPhysician, BOSchildrens:Surgeon, mgh:ThoracicSurgeon, mgh:AdmittingPhysician? Peter did not mention this explicitly, but such type arcs need not be, er, mentioned explicitly. Many of these sorts of roles can be specified, and inferred and validated based on attributes. Also, given a separation of constraints and inference rules, it is not clear that freshly named types would be mandatory for local constraints. I'm not 100% sure if there are some implementation specifics in the stardog 2 implementation of ICV OWL that affect what can be done in each phase, but I know that it has been used for RBAC by some fairly demanding customers, so I would assume it would be a focus point. Side note: It would be interesting to see how the various systems mentioned might express a general rule that (it must be known that) a person who admits someone into a facility must have admitting privileges for that facility, and how that might be further specialized at a specific organization. Not a requirement- would just like to see some comparable idiomatic examples requiring some swrl / sparql type functionality (using plausible extensions if this case isn't handled by currently proposed system). Simon
Received on Wednesday, 30 July 2014 17:09:58 UTC