RE: On classes and property permissions

>-----Original Message-----
>From: public-owl-dev-request@w3.org 
>[mailto:public-owl-dev-request@w3.org] On Behalf Of Emanuele D'Arrigo
>Sent: Thursday, September 27, 2007 11:38 AM
>To: OWL developers public list
>Subject: On classes and property permissions
>
>
>Hi everybody,
>
>another request for info and pointers to info pages.
>
>Assuming I'm trying to build an OWL-based system
>that allows users to edit not only the data but also
>the ontologies themselves, are there estabilished
>strategies to add metadata to the classes, properties
>and their instances so that users are allowed or
>disallowed to add/edit/delete stuff?
>
>Think about this case for example:
>
>- the ontology has a class "file"
>- the class file has a property "size"

Hi again, Manu!

This seems to me as a pretty relevant question. I probably won't be able to
answer it in full detail, but I give it a try, after no one else seem to
have answered until know.

I will assume here that you plan to do inference on your ontology based data
(or at least leave open this opportunity to you), and that you will choose
OWL/DL as your ontology language.

Now, in OWL/DL, you get a noteable problem when it comes to adding metadata
about classes or properties. OWL/DL provides two primary kinds of properties
for ontological modelling: DatatypePropertyS and ObjectPropertyS. For
instance, your 'size' and 'name' property would typically be modelled as
DatatypePropertyS, receiving float's and string's as their values,
respectively. But you cannot use DatatypePropertyS and ObjectPropertyS with
classes or properties as their subject or object part. OWL/DL does not allow
this (or, to put it another way, this would render your ontology into an
OWL/Full ontology). So, you cannot, for example, do something like:

    # your 'size' property
    fileont:size a owl:DatatypeProperty .   

    # a metadata property for tagging resources to be editable or not
    fileont:isEditable a owl:DatatypeProperty ;
        rdfs:range xsd:boolean .  

    # trying to express that property 'size' must not be editable
    # THIS IS NOT ALLOWED IN OWL/DL !!!
    fileont:size fileont:isEditable "false"^^xsd:boolean .

Luckily, OWL/DL provides you an additional type of property: the so called
"AnnotationProperty". You really can assign an AnnotationProperty to every
kind of resource, including OWL classes and properties. So the example above
could be changed to this:

    fileont:size a owl:DatatypeProperty .   

    # the metadata property, now an AnnotationProperty
    fileont:isEditable a owl:AnnotationProperty .  

    # now, tagging the 'size' property is actually ALLOWED
    fileont:size fileont:isEditable "false"^^xsd:boolean .
  
But, as you may have expected, you do not get this just for free. There are
some significant caveats with AnnotationPropertyS:

First caveat: AnnotationPropertyS do not have any semantical consequences
for your ontology, i.e. they do not change the meaning of your ontology.
Technically, this means that the reasoner will simply ignore all
AnnotationPropertyS within an ontology, when it does inferencing on your
data. This fact has good and bad consequences for your case:

    * A good aspect: You cannot accidentally introduce "semantical side
effects" by adding an AnnotationProperty to your ontology. So you can just
add as many annotations as you like to your ontology, without worrying.

    * A bad aspect: If you like to do inference on your metadata, this will
NOT be possible (at least not with an OWL/DL reasoner). For instance, you
might come to the idea to define axioms which express something like:

        "If the class C is deleteable by some group G, and G contains the
user U, then C is also deleteable by U."

      You cannot do this with AnnotationPropertyS! Let's hope that this is
NOT your plan.

Second caveat: You will not be able to build sub-property relationships
between AnnotationPropertyS. So you can NOT specify something like:

    fileont:isEditable rdfs:subPropertyOf fileont:isManagable .

Please check for your specific case, if you need something like this. In
fact, this problem follows from the more general fact that you cannot
specify ANY axioms about AnnotationPropertyS (e.g. also no 'rdfs:range'
axioms).

Ok, let's now see what you actually /can/ do with AnnotationPropertyS in
your specific case:

>- the property "size" -should not- be user-editable
>  bacause it's directly dependent on the actual
>  size of the file stored elsewhere

This works, with an AnnotationProperty 'isEditable' in a way as shown above.

>- the class file has also a property "name"
>- the property "name" -should- be editable because
>  it is reasonable that a user might want to rename
>  the actual file.

Use again the 'isEditable' annotation. So this works, too.

>- however, only some users AND groups of users
>  should be allowed to edit the value of this property

For each allowed user, assign some 'fileont:allowedUser' AnnotationProperty
to the 'name' property. And analog for each allowed group. Works again!

>- additionally, nobody should be allowed to
>  remove the class "file" nor the properties "size"
>  and "name" from the ontology

Add some 'fileont:isDeleteable' AnnotationProperty to the 'file' class,
having value "false". Works!

Of course, you will need a specific ontology editor tool, which is aware of
these special metadata annotations. Because everyone can of course delete or
edit every class or property within an ontology /manually/, or with a tool,
which does not regard this special AnnotationProperties. I am not aware on
any ontology editor, which has some support for this included. 

(I remember that Topbraid Composer [1] has some programming interface, so it
might be possible that you can construct some plugin for this with
reasonable effort, but I do not know. If you are interested, please ask in
the Topbraid Composer mailing list [2] for more details.)

>Should all these axioms be stored in the ontology
>so that whatever application manipulates the instances
>can make use of them directly? Or should they be
>instances themselves, of a separate "permission"
>ontology somehow applied to the ontology "files"?
>Or are there other options?

If you decide for the AnnotationProperty method, I would prefer to put these
metadata annotations directly into the ontology.

Last note: I should not forget to point you to the following document, which
has been edited by the "W3C Semantic Web Best Practices and Deployment
Working Group":

    "Representing Classes As Property Values on the Semantic Web"
    http://www.w3.org/TR/swbp-classes-as-values/

While this document does not exactly handle your case, it /might/ really be
helpful to you in further investigating the problematic situation with
OWL/DL, which I discussed above. Most importantly, it contains alternatives
to the AnnotationProperty methods, with all their pro's and con's discussed.


Cheers,
Michael

[1] http://www.topbraidcomposer.com/
[2] http://groups.google.com/group/topbraid-composer-users

--
Dipl.-Inform. Michael Schneider
FZI Forschungszentrum Informatik Karlsruhe
Abtl. Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: Michael.Schneider@fzi.de
Web  : http://www.fzi.de/ipe/eng/mitarbeiter.php?id=555

FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts
Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Rüdiger Dillmann, Michael Flor, Jivka Ovtcharova, Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus

Received on Thursday, 27 September 2007 20:04:36 UTC