Image Meta-Data

TODO: Image is currently geared towards raster images, not vector images.

Image

extends Item

Read Only
width	int
height	int
xResolution	float
yResolution	float
resolutionUnit	{ inches, centimeters }

Music Meta-Data

The meta-data for the Music class is a subset of the ID3v2.3.0 specification. Only the most significant fileds (the ones displayed by Winamp) were kept as a proof of concept.

We are using javamusictag to handle these.

Music

extends Audio extends Item

Read/Write
Track	int	NULLABLE	TRCK
Total Track	int	NULLABLE	TRCK
Title	String	NULLABLE	TIT2
Album	String	NULLABLE	TALB
Artist	String	NULLABLE	TPE1
Year	int	NULLABLE	TYER
Genre	String	NULLABLE	TCON
Comments	String	NULLABLE	COMM
Composer	String	NULLABLE	TCOM
Original Artist	String	NULLABLE	TOPE
Copyright	String	NULLABLE	TCOP
URL	URL	NULLABLE	WXXX
Encoded by	String	NULLABLE	TENC
Overridden
Length	int		TLEN

Audio Meta-Data

Audio

extends Item

Read Only
Length	int		Length of audio in mills

Item Meta-Data

hese are the schemetized attributes which we feel that belong to every Item.

Item

Read Only
UID	long
fileSize	long
created	Date
modified	Date
accessed	Date
Read/Write
owner	User
group	Group
perms	Permissions
type	MimeType		javax.activation.MimeType
name	String	NULLABLE
stream	File	NULLABLE
related	Collection
User Definable
attributes	Map

Persisted Meta-Data

There are four types of meta-data per Item in SpoonFS.

System Data

Read-only data which is maintained by the file system:

• Date
  • created
  • modified
  • accessed
• File size
• Owner
• Group
• Permissions
  • For owner
  • For group
  • For all
• UID

Persisted Object Schema's Data

Predefined data corresponding to a known type in the file store.

User Attributes

Free-formed user-defined key-value pairs.

Associations

Dynamic

A saved query.

Static

A predefined disjunction of items.

Persisted Object Hierarchy

The decision was made to persist know file types rather than having ad-hoc meta-data schemas. We decided that it was better to have a group of known schemas that users would know what meta-data was available for those types. This helps prevent users from creating version hell with schema types for these well-know objects.

Replaced by Persisted Object Hierarchy #2.

Representative Elements

It should be possible to have a concept of representative elements in a static Association (i.e., an Association without a dynamic predicate). This would allow for a bunch of photos selected of a bike tour to have just one photo be the representative element for the association. One way to implement this would be to have each Photo have a Representative field, which points to the actual representative photo. Of course, then photos can be part of only one representable set. Perhaps the representative should be stored with the Association. So you ask an Item for an Association that it's part of, and then ask the Association for the representative element. If there is no representative element, just show all elements.

Again, representative elements should only be valid for static associations. If it were a dynamic Association and an element E were picked, if E's state changed so that it was no longer part of the Association, what would that mean? We would have an Association whose representative element was not part of the Association. Maybe this should be allowed, but it seems kind of dumb (e.g., why have a 10 day old e-mail be representative of the Association "All e-mails less than 7 days old"?)

As an alternative, perhaps we should meet in the middle and only allow static members of Associations to be representative. That is, when the person wants to make the member of an Association the representative, its inclusion in the Association had to be satisfied by a static part of the predicate (e.g., a particular UID) and not a dynamic part (e.g., age <>

Anonymous Associations

Since Associations are Items and the Name field is optional for Items, it is possible to have Anonymous Associations. Such a creature is useful if, for example, you just want to say that a group of things are related. E.g., I just select a bunch of photos from my bike tour and say that they are related. Sure, I *could* say that they have the name "bike tour", but why? I should just be able to associate them and not have to worry about naming immediately, especially since I can get an Item's Associations from the Item itself.

Attributes and Tags

Services like Flickr offer Tags. Attributes are more powerful than Tags. Attributes are key-value pairs. If you want tags, you can make an attribute without a value. Also, Attributes are type-safe. If you specify a Date, you get a date object. If you specify the type as Contact, you get a Contact.

Association Implementation

It is possible to implement Associations with Attributes. But don't do this.

Typesafe Attributes nd Relationships

Since attributes are typesafe, full relationships can be made. For example, it is possible to have Person Items listed as attributes of a Photo Item (e.g., if the person is in the photo). This allows for very powerful queries to be developed (e.g., show me all photos of Candice taken last year).

Associations

Definition

As discussed before, a traditional filesystem has Files and Directories whereas SpoonFS will have Items and Relationships. This post describes Associations and their usage in the filesystem. Formally, an Association is just a unordered set of Items. In this respect, an Association is similar to a Directory in a traditional file system.

Simple Example

However, the power of Associations extends much further than Directory capabilities. First of all, it is possible for Items (for now, just think of Items and Files as being the same) to be in more than one Association. For example, imagine that Alice has recently taken several photos from her vacation in France. One thing that she could do is create a new Association named Vacation and put all of the recent photos in this Association. Furthermore, assume that Alice visited France because of a fascination with the Eiffel Tower. Alice has several photos from other people of the Eiffel Tower and these are all under an "Eiffel Tower" Association. Now that Alice has taken her own photos, she can also put these under the "Eiffel Tower" Association. Note that this would have been very difficult to do in a hierarchical file system; a picture of Alice in front of the Eiffel tower would need to be in both an "Eiffel Tower" directory and a "Vacation" directory. A hacky solution is available on platforms supporting hard links, but many mainstream filesystems (NTFS and FAT32) do not support this feature.

Associations are Items too

As a parenthetical comment, it was mentioned that Items should be thought of as just being Files. We now extend the concept of a SpoonFS Item to include Associations as well. That is, an Item is either a File, a Spoon, or an Association. Since Associations are sets of Items, it is possible to have Associations contain other Associations. Such a use for sub-Associations could be useful in organizing system files. For example, consider a "School" Association consisting of all of the work done for school (e.g., essays, assignments, OS projects, etc.). Now consider that there is an Association named "CS508" which corresponds to any files having to do with CS508 (e.g., PDF documents corresponding to the papers read). "CS508" could be placed as an Item in the "School" Association (along with other Associations pertaining to courses). Using Associations in this way is mirroring the functionality of a hierarchical file system. In fact, with this example, we wanted exactly a subset type of relationship, which is what hierarchical file systems provide. This example is useful to demonstrate that Associations are more powerful than just hierarchies: they can implement hierarchies (i.e., sub-Associations), but can also do much more (e.g., look at the previous example involving vacation photos).

Dynamic Associations

As defined, Associations are sets of Items. The examples provided so far have offered sets that have a static predicate function. That is, the Association is told that it contains "these files", where "these files" are some set selected by the user. However, the predicate function for an Association can also be dynamic, allowing Associations to grow dynamically as new files are added. As a requirement, we allow Associations to query over the Attributes of an Item. For example, consider an Association entitled "Favourite Songs" in which the predicate function is "All MP3s whose "rating" attribute is 5 or more". An example from business could be "All Contacts that I have sent an E-mail to in the past five days". In this respect, Associations act somewhat like stored queries or views in a database. There is already a similar concept built into modern e-mail clients called virtual folders (such clients include Novell Evolution, Mozilla Thunderbird and Microsoft Outlook). Of course, virtual folders are only defined for mail messages in these applications. The great thing about refactoring this type of powerful behaviour into the filesystem is that all SpoonFS aware applications can benefit from it.