W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > July 2014

Re: AW: Thoughts on validation requirements

From: Simon Spero <sesuncedu@gmail.com>
Date: Wed, 30 Jul 2014 13:09:31 -0400
Message-ID: <CADE8KM6xNZScaCUNUQAz6KigAN-EJVrKBZkEPxy0fzvZk7pQ+A@mail.gmail.com>
To: "Eric Prud'hommeaux" <eric@w3.org>
Cc: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>, "Bosch, Thomas" <Thomas.Bosch@gesis.org>, public-rdf-shapes@w3.org
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

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).

Received on Wednesday, 30 July 2014 17:09:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:39 UTC