Consider check-out / check-in of documents as activity types

[rpeinl]

Another use case that I have is document management (DM). Since AS 2.0 supports Document, Folder and the CRUD operations it seems well suited for that use case. However, an important operation for DM is locking a document for exclusive editing (yes, there are still many systems working without collaborative editing features ;-)) and releasing that lock after the editing is completed called check-out and check-in.
AS 1.0 had checkin as a verb, but with the meaning of checking-in to a place like with Foursquare or Facebook Places. AS 2.0 has dropped that.
I would be happy to see that activity pair in AS 2.0 with the DM semantics implied.

[jasnell]

-0 on this one. I definitely see the use case but it's something that can be easily accomplished in an extension vocabulary built on top of the core.

[jasnell]

@rpeinl ... btw, don't let my -0 or comments discourage you on this. If you feel strongly that these should be included in the core vocab, definitely make the case! I'll be making sure that all the proposals opened here make it onto the upcoming call agenda for consideration :-) ... fwiw, my default stance on adding new terms to the vocab is going to be negative in general because I want to avoid the vocabulary growing unnecessarily, but if a case can be made for specific individual terms then I can be easily swayed ;-)

[rpeinl]

Thanks James for the clarification. I was not discouraged. I just didn't want to repeat the arguments from #239 for the other two issues. I can understand your reluctance to expand the vocabulary at this time, but I had to wait a long time before being included in the WG and therefore did not speak up before. I'm afraid there will be more requests from my side since I find extensions easy for object types, especially if the additional types have no special attributes, but hard for activity types. As I said, from my perspective interoperability is the ultimate goal and I don't now how to achieve this with company-specific extensions. It would be different if those extensions were published on the W3C website or at least directly linked from the main spec. Maybe that is a compromise to further distinguish between extended classes (as you call it in the vocabulary document) and extension classes or profiles for certain use cases, that do not have to be supported by every implementation. Something like: you don't have to do that, but if you do, than exactly like that.