Saturday, September 19, 2015

Considering Bibliography and Filesystems

While Git clones EFL WebKit onto my GraniteLAN, there is a short while as to develop a thought towards a concept of bibliography: That in the known universe, there exists a book about SysML, and there exists an article towards a mathematical perspective of UML. A mathematical perspective of such a topic, perhaps, may be presented as towards something of a literary discussion about a sense of a philosophical and practical relevance of the Metaobject Famework (MOF), and the corresponding metamodels of UML and SysML as dialects of systems modeling, such as may be applied moreover towards a systems design.

I'll try to develop a logical model of a concept, presently, as towards developing a logical model of software components, abstractly, and of components bundled materially in the EFL WebKit changeset repository – a changeset repository stored and accessible with Git.

Preliminary to developing a UML modeling profile for software source code components, I would firstly like to share a set of notes that I've collected as with regards to bibliography. I'm afraid that it cannot be a trivial effort, however, as to begin a thesis about bibliography, forthwith. Presently, there is a matter of the bibliography for any thesis about bibliography.

The article – as towards a mathematical perspective of UML, in the known universe –  the article, in a PDF edition of its presently unnamed publication, it is presently located in a private Git repository on my notebook laptop.  I had moved the file to there – effectively, relocating the file from its initial on-LAN location, then stored on the internal filesystem of my own academic dashboard of a tablet computer, moving it then to the FreeBSD UFS filesystem on my Notebook – that procedure, as when I was trying out git-annex as a file synchronization tool. Not to short git-annex of attention, I don't believe a Git repository may be an ideal resource for a mobile filesystem. The 'dot-git' metadata directory of a source tree managed with Git, that may seem to present something of a waste of limited mobile storage space, as it is for storage of data that may not be immediately accesed by a Git user, outside of each individual changeset registrstion.

Since the time of making an initial study about git-annex, approximately one week ago, I've read a small amount of literature about SparkleShare. I wonder, now, as SparkleShare implements a manner of a virtual filesystem, may it be approached as to develop a manner of a CORBA filesystem service framework? SpakleShare is available as free/open source software, juxtaposed to Dropbox, Box.net, or similar closed source, web-oriented Cloud Storage services.

This morning, while developing an outline about networked filesystems available on FreeBSD, I'd read some little about GlusterFS, and some little more about network services available to a model of classical UNIX networking. Though, personally, I am not immediately decided about applying either GlusterFS or NFS on my GraniteLAN, this afternoon, however I'm considering both of those networked filesystem models – as towards a manner of a DevOps regards – for application in integration testing and continuous availability i.e software distribution, but on a local area network (LAN) only, of a custom compiled FreeBSD 10.2 kernel and FreeBSD 10.2 base system on GraniteLAN.

So. There's to a service oriented view of filesystem services – as in a manner, a view corresponding with a generic concept of "File", howwver applied as onto a concept of a "Private network." There are the GlusferFS and NFS network filesystems, and alternately, SparkleShare as a centralized virtual filesystem.

Three types of filesystem – it might be enough as with which one may develop a manner of an outline of a thesis article. There might be a concept of mathematical topology, correspondingly developed – perhaps, towards an abstraction about data and computation, and a conept about illustrating a graph of data.

[Draft nr. 5]


Some notes about Bibliography, focusing on bibliographical tools
  • Mendeley Desktop (Microsoft Windows, version 1.14)
    • When importing a BibTeX file, in regards to attachments (files), Mendeley Desktop does not parse relative filenames as expected
      • If an attachment is referenced in the BibTeX file with a relative pathname -- such as when the BibTeX file is generated with Eratosthenes, then as when attaching a document to a BibTeX entry -- the attachment will not be added to the user's Mendeley files, as expected. Mendeley, instead, will report as if the file does not exist. 
      • A workaround exists for this unexpected software behavior: To remove the "Not found" attachment's entry, in each Mendeley bibliography entry, then to attach each file manually
    • When saving the user's bibliographies in BibTeX format:
      • Effectively, the files are saved in read-only format. Changes to the files will be overwritten by Mendeley Desktop
      • For a set of bibliography files saved by Mendeley Desktop into a directory 'bibsync', the BibTeX *.bib files saved within 'bibsync' will change in unexpected ways, over time
        • Mendeley Desktop does not always save the set of  BibTeX entries in the same order of entry, within each file, at each time of synchronization
          • If the 'bibsync' directory is managed within an SCCM repository, this will result in file changes, though the BibTeX entries themselves may not have changed, in any single one.
        •  If the user has configured Mendeley Desktop to organize the user's bibliography attachments, as to save the files within a directory 'bibsync/files', then in each entry in 'bibsync/*.bib', every attached file within 'bibsync/files'will be referenced with an absolute pathname as would be generated on the filesystem or origin.
          • This may seem to present a minor challenge, as in regards to utilizing the generated BibTeX files with services not including Mendeley Desktop -- such as when the bibliography files are synchronized into an SCCM repository, or if the bibliography files would be posted to any single web service
  • Eratosthenes (Android)
    • Eratosthenes Wiki [Bitbucket]
    • Eratosthenes Issue Tracker [Bitbucket]
    • Not open source
      • Not uncommon, on Andoid
    • Supports bibliography formats generated with JabRef, BibDesk, and Eratosthenes
    • Great UI
    • May be difficult to synchronize between tablet and desktop
      • Tried: Synchronizing bibliography metadata and files, using git-annex
        • Though git-annex has its applications, but in considering the limited filesystem storage capacity available of thin client mobile appliances, the dot-git repository of a git-annex repository consumes storage space to no great effect. This is more pronounced, perhaps, for storage of binary formatted files, such as of documents in the Adobe PDF format
      • Unavailable, presently: GlusterFS on Android
      • Available, but with reservations: Dropbox
        • A user's Dropbox storage is manageable via the central DropBox web site, or on filesystems with the user's central/cloud DropBox storage completely synchronized to the filesystem
        • Synchronization not obviously available for Android
        • Synchronization not manageable by the LAN administrator
      • Unavailable, presently: Sparkleshare on Android

No comments:

Post a Comment