A work in progress, by James Howison, for an ontology for detailed events in Free and Open Source Software development Projects (FLOSS). Currently it is stringly biased towards communication venues and Events, and isn't integrated with other relevant ontologies, like DOAP, EvoOnt and SIOC.
A work in Progress, by James Howison, for an ontology for FLOSS artifacts. It is biased towards communication venues, and isn't integrated with other relevant ontologies, like DOAP and EvoOnt. The URL doesn't resolve as yet.
A specific version of a SoftwarePackage. eg Fire.app 0.36.a is a Version of Fire.app. These are made available through a SoftwareReleaseEvent. In common parlance they are often called 'releases', but Versions helps keep the emphasis on the specific realization, rather than the event of releasing.
The release of a software package. This is usually accompanied by a set of release notes and a change list.
An SVN commit event.
A class to represent the Comment of a Tracker item (note that this perhaps ought to be aligned with EvoOnt).
A message typed in by a developer as they issue svn commit or similar.
The listing of an individual developer in a developer List. TODO: Model as an n-ary relation to allow different roles (ie it's a characteristic on the property linking DeveloperListing and an Identifier. Probably this becomes a Role listing.
Clearly this needs an event_date datatype property.
Identifiers where the hasContent is known to be unique. These can safely be used to merge Participants
A listing of developers, and their named roles. This is an example of a Venue that is not a CommunicationVenue. Each listing of developers is an event in this Venue.
Communication venues are those whose events have Documents
An 'abstract' piece of software, eg Fire.app. These are realized in SoftwareVersion, which are associated with a Release event.
A class to represent the submission of a Tracker item (note that this perhaps ought to be aligned with EvoOnt).
A ThreadedVenue can have Threads, Projects can inherit this property
This property links Containers of Events (Threads, Venues, Projects) to the Participants which performed the Events. It is probably specified through a Role Chain or SWRL rule.
The identifier string used to identify who made a commit. With SF SVN this is always the SF username.
A meta property for linking an Identifier to an Event which the Identifier is associated with. Usually this relationship would be specified from Event to Identifier, with this inverse relationship as a convenience.
Links Identifiers to Participants; This ought probably to be implemented using foaf:nick or similar.
Links Events to Event Containers (Projects, Venues, Threads).
Links Events to Participants.
Links a CommunicativeEvent (MailingList msg, Forum msg, Tracker Comment) to the Identifier which is said to have sent the message.
Used for CommunicationEvents that have a threaded structure (MailingList and Forums)
Links Participants to the Events they performed. Note that it is different from hasEvent, which only applies to Event containers (Project, Venues, Threads).
Links Threads to Venues. Link can be transfered to the Project that owns the Venue.
Links Participants to Identifiers
Links an identifier for a Sent msg (MailingList, Forum, Tracker Comment) to its Event.
The Participant performed at least one event in the Thread, Venue, Project.
Links a Developer Listing with the identifiers that it lists
Links Threads, Venues and Projects to Events. Note that Participants do not use hasEvent, they use didPerform.
Events are the primary holders of Documents, but the documents can also transitively belong to the containers that use hasEvent (Thread, Venue, Project).
Links Projects to Venues
A DeveloperListing listsIdentifier Identifier
Property linking Documents to their Events and transitively to the EventContainers (Projects, Venues, Threads).
A meta property for those properties that link an Event to the Identifier said to perform it.
The sf project name. Roughly equivalent to doap:name?
The Body of a communication message document
The sf name for a venue. eg gaim-cabal or users-helping-users (a gaim forum)
The subject of a communication document (probably should use dc:title or similar
The SF id number identifying the Tracker Item. This is used to 'name' the Thread. The submission is an Event in the thread, as are the Comments.
Used to store the content for Identifiers and Documents
This shows which the next SoftwareRevision of a Package is. It is a 'way around' the Open World Assumption, where you know what the next revision is. This idea was taken from the rcs ontology: http://semweb.ivx.ch/software/rcs.