Opened 5 years ago

Last modified 5 years ago

#716 new enhancement

File owner is here but group is missing

Reported by: evgeny.egorochkin Owned by: AntoniMylka
Priority: trivial Milestone:
Component: ontology-nie Version:
Keywords: Cc: evgeny.egorochkin


nfo:FileDataObject provides owner and permissions properties but not group which makes POSIX file permissions implementation incomplete.

Change History (3)

comment:1 Changed 5 years ago by evgeny.egorochkin

  • Cc evgeny.egorochkin added

comment:2 Changed 5 years ago by leosauermann

should we use nco:ContactGroup as range of group?
It is a bit awkward, we have the same problem here as with the emails (#698).

 rdfs:range nco:ContactGroup;
 rdfs:domain nfo:FileDataObject.

the permissions are also not well defined:
"A string containing the permissions of a file. A feature common in many UNIX-like operating systems."

can we describe this better? Is there a platform independent way of representing permission patterns?

comment:3 Changed 5 years ago by evgeny.egorochkin

If we go the "owner,group,permissions" route, we implement POSIX ACL(Access Control List) and not much more.

If we want to also implement Extended ACL and whatever windows has, we could end up with a pretty complex ontology.

An example of RDFied ACL would look like

  nxx:canBeWrittenBy user:UserGroupX;
  nxx:canBeReadBy user:UserY
  nxx:canBeWrittenBy user:UserY

The question is how to best represent "Others" group in POSIX. Which is supposed to include everyone(same problem as with representing public communication channels btw).

Adopting such an approach would provide a good approximation for all existing implementations. Unfortunately it's read-only one because real implementations have nasty^H^H^H^H^H useful features that complicate matters like ACL inheritance, masks and whatnot. We either have to represent all those features properly or store "effective" ACL, that is a list of who can do what based on ACLs, masks etc.

Note: See TracTickets for help on using tickets.