A crucial part of getting the first class object set / model correct is having the right terminology, both individual and plural. FCOs must be immediately understandable, and easy to work with in general conversation.
Contents
1. First-Class Objects
1.1. People
- contact info, VCARD essentially
- There are different ways of regarding people:
- Team
- Group
- Contacts
RyanMcDougall: a Group is itself a first class object, a Team is a special kind of Group, and a Contact is a strict subset of Person, no? For example, a Person might also include a Galago Presence, birth date, ethnicity, etc? I think Contacts often go beyond what is strictly contact info, into the realm of the personal.
1.2. Documents
- Not just office-type documents, but also random files.
- A canvas that handles al editing / creation. Gnome could implement the following.
- 2D canvas (documents and images)
- 2D canvas + time (video)
- 3D canvas (CAD)
- 3D canvas + time (animation)
1.3. Email
- individual messages
- Could threads also be regarded as Conversations?
1.4. Conversations, Discussions
How do you map IRC nicknames to contacts? Contacts don't have an "IRC nickname" field, do they?
HavocPennington: all apps should use the Person object to represent any persons visible in the app. So you want to be able to associate all kinds
of address with a Person. (Also, no designing a user-centered desktop around IRC 
do the chat UI, then figure out the protocol)
MikeHearn: I think Galago supports this (IRC nicks -> abstract Person). Galago definitely seems to provide what is needed here.
1.5. Appointments, Events
JeffWaugh: In the traditional groupware appointment sense, but also 'events', and a way to associate other first-class objects with times/dates.
1.6. Tasks
- Todo lists, bugs, etc.
- Tasks can have deadlines or priorities, so they are somewhat like Events
1.7. Search Results
- objects that implement search interfaces
- saved searches, eg bookmarked Google URL - just save the query and be able to rerun it whenever it's viewed a la BeOS
1.8. Projects
A Project is a set of related first-class objects. A Project "bundles" any of the other first-class objects, including other Projects.
1.9. Images
What can we do here thats useful as a generalization? Image [Title | Date | Subject | ...]? Does EXIF capture everything we want to know? Would GImage be just a wrapper for EXIF metadata?
1.10. Music
Similar to Images, does iD3 give us all we need to know? What about CDs or WAV files?
TravisReitter: for CDs, we could always probe Freedb.
NicolasTrangez: ID3 is (AFAIK) MP3 only. We also got metadata in ogg (vorbis and others) and even other formats. MusicBrainz can be usefull too.
2. Under Discussion
2.1. Programs
People want to exchange software. Does this makes sense? Sandboxing / Zero Install / etc.? See PackagingAbstractionLayer.
RobBrockway: Software packages could easily be first-class objects - they could be binary packages (the object would represent an RPM or Debian package file, or equivalent) or, for developers or people who want to compile stuff themselves, source packages (here it would represent a source tarball).
2.2. Changesets
Should all first-class objects have revision control? Give me diffs, etc. If "version tracking" == "change sets", then change sets are first-class objects as well. Or are they metadata on the objects? What about a global Recent Changes list, like in this Wiki?
2.3. Access control
Should everything have ACLs? Is this metadata, or are ACLs genuine first-class objects?
Objects in a Project may only be available to the People in that Project? <- involves cryptography, possibly.
RobertStaudinger: ACL is a very techy term. Maybe this functionality could be presented to the user by creating a "Share" / "Pinboard" / "Shelf" first-class object to which other objects can be linked to. Assigned People would have access. See the PrivilegedOperations discussion. In the mailing list thread MikeHearn argued that for home/single user/family desktops the default should be that all files under /home are available to all users by default rather than having a discrete drop-box share area. RyanMcDougall: Aside from a Nautilus UI, I think this is a packaging or distro problem?
2.4. URIs
Or are they just a way to refer to first-class objects? Are they monikers?
HavocPennington: neither URIs nor monikers are user-interesting, though URIs are perhaps something users are forced to be interested in, the question is whether you need an object or just strings.
2.5. Time
Or is time just metadata on first-class objects?
How would a dashboard show you all the stuff that you accessed around a certain date? Example:
- Highlight a date in your calendar. Dashboard picks up a "date" cluepacket. Time backend starts searching for items that happened within 2 weeks of that date.
RyanMcDougall: I think this is a very interesting Second class object. It would be handy to pass around a standarg GTime.
2.6. Location
Same as with time, is it just metadata for first-class objects? "I want all documents that I wrote while I was in Norway" <- useful for frequent travelers; they may remember where they wrote something, but not when they were there.
RyanMcDougall: Wouldn't country codes (us, ca, uk, jp, etc) be sufficient for a GCountry?
2.7. Emotions
GlynnFoster: Do emotions change the way we use or approach our software? If so, how?
2.8. Videos
TravisReitter: It seems that if we include audio and images, we should include videos.
3. Current projects
3.1. Frege
I (JoeGeldart) have developed a shared information layer that exposes an RDF graph over DBUS as part of my dissertation. The report I wrote is at RDF without Revolution and a current snap-shot of the code is at Frege source-code. The system provides a shared storage layer (with support for smushing nodes along functional and inverse-functional properties) and a set of bindings for python (although other languages are planned) that makes using information from the graph as easy as idiomatic OO. I am currently researching adding features to allow temporal (and other modal logic) modelling of information. I am also developing ontological descriptions of user interfaces to allow a better modelling of task interaction so that software can be modularised in a more task-oriented way and then joined together as appropriate. I plan for Frege to be the first system to take advantage of the theory of identity I'm researching for my doctoral proposal. It was quite a big project. But I feel I've run through most of the issues Soylent will do, and found solutions to them. The open research questions are a lot more precise now, and infinitely easier to hit. One of the most important is that you're inevitably going to reinvent the RDF data-model if you build an open information system such as a this inevitably must be, so you may as well start with the RDF data-model. I agree with people who criticise the RDF/XML serialisation for being awkward, however it isn't the only serialisation in town and it is not the main part of RDF -- the data-model.
3.2. Tracker
The Tracker project already uses RDF to represent queries and sets of objects. In addition the project aims to represent first class objects natively