Seth Ladd blogs about the inclusion of provenance and time labeling in RDF, partly in response to John Barstow's earlier wish list for RDF-Lite. Seth makes an excellent point about how the time aspect can be easily modeled in RDF already, by creating an object for the event occurrence.
However, there are definitely cases where the solution illustrated by Seth is awkward. Consider for example an electronic archive which contains photos of buildings. The photos are annotated with the street address, but for some few buildings the name of the street has changed over the years (or in rare cases the building itself was moved). We can capture this by thinking in Nouns, for example something like this:
:addressOccurrence1 :ofBuilding :building1 ;
:street "Church Street 24" ;
:startYear "1939" ;
:endYear "1948" .
:addressOccurrence2 :ofBuilding :building1 ;
:street "New Church Street 17" ;
:startYear "1948" ;
:endYear "2006" .
Although we do accurately capture the time-aspect of the notion of address, we end up with a very un-intuitive model here. Most of the time in querying this archive we will simply want to consider the address of a particular building without caring about dates, it is only in some corner cases that the temporal aspect is important. However, the chosen modeling makes little sense if we disregard the temporal aspect, making it an ill fit (think of the kind of SPARQL query you'll need to get all current addresses of all buildings. It's possible but not pretty).
Anyway, whether the solution works well in all cases or not (and I'm sure there are other modeling solutions possible for the example I just gave), a tacit assumption in general seems to be that in order to incorporate both provenance and time in the RDF model, we need to extend from triples (subject, predicate, object) to not just quads but quints (subject, predicate, object, source, time) or something like that.IMHO this is not necessary and a simple extension to quads allows us to do everything we want already. The trick is to not think of the fourth parameter as the provenance identifier but merely as a group identifier, which in its own right can then be used as the subject of many statements about the group (such as its source, and possible start and end times, or how Jeen feels about these statements, etc. etc.).
In fact, this is almost exactly how named graphs in SPARQL work: by offering the means to identify groups of statements by an identifier without assigning any semantics to that identifier we can then use that identifier to encode all sorts of properties about groups of statements, including provenance and time properties. What would still be useful as an extension would be standardized vocabulary for denoting provenance (e.g. rdf:source) and time labeling though. For the latter, something like the OWL Time Ontology might be useful.