RE: A question on the vocabulary for 'persons' - ACL level of granularity?

> Absolutely.  However, concensus on a placeholder class for a 
> person doesn't prevent you from extending it with other 
> attributes (or relationships with other classes) at a latter 
> point - that's one of the advantages of the expressiveness of 
> Description Logics.
> 
> Seems to me the biggest barrier is in coming to a concensus 
> on an appropriate placeholder vocabulary and not neccessarily 
> on determining all the various ways in which a person (and 
> their related data) could be expressed in a patient record.

+1

Let's not to worry about those extensions now.  When Ivan brought up this
topic, I think what he meant is a very general use cases, much more in the
scope of the vCard. Otherwise, we will be in an endless debate on what kind
of properties we should put in a Person.  A Person is what a Person is.  The
first thing to do is to specify the most "desirable" properties across all
areas, not just in the LSHC.  Then, we can develop different kind of Person,
Patient, Doctor, Nurse, Researcher, etc., But all of them should share some
common properties like name, email, address etc. 

> I'm glad you brought this up.  I've been of the opinion for 
> some time that issues of security policy (from the perpective 
> of content management systems at least) are often overlooked 
> within Semantic Web technologies and that Access Control 
> Lists are a very appropriate model to follow.  The structure 
> is very simple, and it is a time-tested infrastructure for 
> delegating identification-driven access to resources.
> 
> A follow-up question I have about this is if we imagine (for HCLS
> purposes) access control being specified down to the level of 
> triples *within* a graph (assuming a partitioning scenario where each
>   patient record constitutes a named graph) or if ACL would 
> only manage access at the record level.
> 
> The distinction is important as the content management system 
> we use controls access to the record (or graph) level 
> allowing content ontologies to remain ACL-agnostic - and 
> delegating access control as a mechanism of the content 
> management system.
> 
> If a finer level of granularity is needed, it does suggests 
> the need for a general-purpose ontology for ACL.

At this stage, I wouldn't worry about this yet. Of course, the issue of
privacy is important, especially when it touches the patient's record.  But
if you look at the semantic web stack, Trust is on a higher level than the
Logic step.  And we are just at the beginning stage to standardize
vocabulary. Thus, my opinion is: for now, just assume an open and trusted
world.  If access control is needed, impose it at other level (ACL, or any
other suitable technology).  

I remember at the first F2F meeting what TBL said.  "Let's put things on the
web first, then worry other things later". (It is how I remembered but not
how TBL exactly spelled out).

In the web, we communicate via SHARING information. And how SHARABLE a
resource is actually determines how effective the communication will be.

So, the very first thing to do is, as TBL suggests, to ground our things on
the web.  I.e., give them URIs.  Then, make them accessible (that is why I
prefer httpURI over LSID because of more accessible).  Third, in terms of
developing ontology, start to wonder how SHARABLE the ontology will be. A
general ontology is usually more sharable than a detailed ontology. So,
let's settle the general ontology first and then design the more detailed
ontology later.  Then, we start worry other things...

Cheers,

Xiaoshu

Received on Thursday, 14 September 2006 15:03:02 UTC