SemFS/Semantics

From semanticweb.org
Jump to: navigation, search

Documentation for the Semantics of SemFS - note that this information may not be up to date


Contents

[edit] File System Structure and Operations

Within the logic of this knowledge filter, all typical file system operations map to manipulations of the underlying metadata and/or content store.

  • list directory (path) - By means of the registered filters, this operation translates the given path argument into a list of constraints which are merged into a conjunctive query against the knowledge base. The operation then lists the name of all files which match the respective query. It further lists also directories, namely those that map to a further restriction that would refine the current result set. For example, given that at least one of the results retrieved by the above query would also carry a further tag, e.g. ontology, then the directory ontology would also be listed as a possible refinement.
  • create file (path, local file name) – This operation is either invoked if a new file is created or an existing file outside of SemFS is copied or moved into a SemFS location. In both cases, a new resource is created (in the case of a copy/move operation the file content is further processed by the respective ClassHandler) and, by means of the knowledge filter expressions that the path maps to, it is forced to take all properties required to be a valid resource at this location. E.g. if a new file would be created at /active/semweb/city=karlsruhe, the tag statements mapping to active and semweb as well as the city statement mapping to Karlsruhe would be added to the new resource. As noted above, this can be non-trivial in the case of very advanced filters – an issue which we do not discuss here.
  • read file (path, local file name) – Render/read file content from metadata and/or content storage by means of respective class handler.
  • write file (path, local file name) – Parse file content and write to metadata and/or content storage by means of respective class handler.
  • rename file (path, old local file name, new local file name) – Change name in metadata of the respective resource.
  • delete file (path, local file name) – Remove all properties from the respective resource that are produced by the submitted path.
  • create directory (path, local directory name) – In theory, this operation should not yield any result as the newly created directory would be empty and should thus not show up as a refinement of the parent directory. However, a placeholder file/resource can be created that carries all relevant properties but is removed after a certain timeout.
  • copy file (old path, local file name, new path) – Add all properties produced by the new path to the respective resource.
  • move file (old path, local file name, new path) – Remove the property produced by the most specific path element in the old path from the respective resource and add all properties produced by the new path to the respective resource.

[edit] Operations by example

Given the following tags: "A", "B", "C"

Given the files:

  • a.txt - tagged only with "A"
  • b.txt - tagged onyl with "B"
  • ab.txt - tagged with "A" and "B"
  • abc.txt - tagged with "A", "B" and "C"

Rule: If a file "x.txt" is shown in a folder "ROOT/A/B", it has the tags "A" and "B".

[edit] Adding

Adding x.txt to folder ROOT/A/B

  • tags x.txt with A and B
  • When now adding ANOTHER file named x.txt to ROOT/A/B
    • option 1: throw error
    • option 2: update file contents (overwrite)

[edit] Deleting

Trade-of issue: When moving a file away from a folder (by delte or move), should that apply semantics on all tags in the path or only on the last tag?

  • Our solution: To the last tag only.

Deleting "abc.txt" from folder "ROOT/A/B"

  • option 1: We must now at least remove the last tag (here B)
    • result: abc.txt is now tagged with "B" and "C". -- ACCEPT delete last
  • option 2: But we can also remove all tags from the file.
    • result: abc.txt is now only tagged with "C". -- REJECT

Deleting folder "B" from "ROOT/A" => equivalent to removing all resources in ROOT/A/B

  • remove the tag "B" from all ressources appearing in ROOT/A/B
  • tag "B" still exists
  • other resource can still be tagged with "B"

Somtime we need special semantcs. They happen in a folder called "magic".

[edit] Moving

Is generally considered as removing and adding.

Personal tools
Namespaces

Variants
Actions
Navigation
services
Toolbox