[foaf-dev] Proposal: deprecate pastProject and currentProject

Simon Reinhardt simon.reinhardt at koeln.de
Sun Dec 13 00:04:31 CET 2009


Damian Steer wrote:
> I think the proposal was 'deprecate' rather than 'remove'. The difference can be significant:
> 
> <http://java.sun.com/javase/6/docs/api/java/util/Date.html>
> 
> Deprecated for over a decade, and still going strong!
> 
> So don't be sad :-)
> 
> Damian

The Java Date class has never been deprecated, just the methods and constructors which are calendar-specific because the Calendar class was introduced to abstract from various different calendars.

Anyway, concerning pastProject and currentProject I think the problem really was the times in the names. When do you classify something as a past project? Maybe you're not working on it at the moment but you don't consider it finished. That might have hindered adoption.

I would deprecate them both but at the same time make them sub-properties of a new property foaf:project. That property should have a range of foaf:Project. I do realise that this will lead to the inference that foaf:pastProject and foaf:currentProject also get that range but since they would get deprecated anyway I don't really see that as a problem (and after all you don't have to subscribe to that particular version of the FOAF ontology if you don't want to :-) ).

Sure you could say that since the old properties didn't get much adoption why add a new one? Well, I think it's worth adding it just as an experiment to see if maybe that will take off.

I'm not too keen on Toby's foaf:projectHomepage proposal. I think we've got enough resources on the Web of Data now to make it possible to identify projects rather than project homepages only and in all other cases you can identify a foaf:Project via its foaf:homepage property.

Regards,
  Simon


More information about the foaf-dev mailing list