Re: AW: Thoughts on validation requirements

On Wed, Jul 30, 2014 at 8:09 PM, Simon Spero <sesuncedu@gmail.com> wrote:

> 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).
>
It should be fairly easy with SPARQL. In RDFUnit I am in favor of small
reusable test-cases so I'd implement it in the following way (something
similar should apply for SPIN I guess):

 There are many different ways to models this, unless you have a specific
model I Assume the following:
- we are talking about foaf:Person's
- we have a Class :Admitance with 3 properties :accessFrom, :accessTo,
facility (and cardinalilty 1 for each)
- property :accessFrom range foaf:Person
- property :accessTo range foaf:Person
- property :facility range :Facility

validation:
1) sparql queries to ensure all domain / range restrictions (2x3 = 6 tests
cases)
2) for each property we check it's cardinality, 1 test to check if property
exists and 1 test to check if cardinality != 1 (2x3 = 6 test cases)
3) sparql query to ensure accessFrom != accessTo (disjoint properties in
OWL) (1 test case)
4) the actual check: something like:
 ASK {
  ?newAdmitance :accessFrom ?person
  ?newAdmitance :facility ?facility.
  FILTER exists { ?existingAdmitance :accessTo ?person; :facility
?facility.   }
}

So in total with 14 different test cases (SPARQL queries) we ensure what
you ask

extra: if we would like to allow admitance to "subFacilities" as well we'd
have a property "isSubFacilityOf" with domain / range Facility and
cardinality 1 (2 test cases for domain / range + 2 for cardinality)

Using property paths we can alter #4 to also check for "?subFacility
isSubFacilityOf+ ?facility"
(the query will get more complicated but you get the idea)

In addition we could define an extra rule to check for facility hierarchy
cycles
{ ?f isSubFacilityOf+ ?f .)

Best,
Dimitris



>  Simon
>



-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org
Homepage:http://aksw.org/DimitrisKontokostas