Re: annotation status property proposal

Marja Koivunen wrote:
>
> Thanks Mark for doing this!
> 
> I have couple of questions and thoughts because I want to understand 
> better what we are doing from user point of view and see what other 
> options we have before committing to one (or maybe we can have several 
> options):
> 
> 1) what the user wants to do,
> 2) how does is work with other users, and
> 3) how to visualize it in the user interface.
> 
> UI extension for schema extension?

It does make sense to me to talk about use cases, although I think the 
status concept is very general and may be used in many different ways.


> Point 3 is a question that has been on my list a long time and we did 
> some early experiments with IsaViz presentation rules. After using xul, 
> and scripting I think it would be interesting to see if those could 
> solve the problem. This question is important to answer so that when the 
> schemas are expanded the ui can be expanded at the same time as well. 
> But that is a project a bit further away so let's concentrate first on 
> extending the schemas because user wants to do something a bit different.

UI design strikes me as a somewhat implementation-specific issue, so I 
too would rather talk about schema first (while keeping possible UIs in 
mind).


> Embedd status as a property to the annotation itself:
> 
> What kind of user interface you see for the users who change the 
> status?  Sometimes changes to annotations may be restricted, for 
> instance, because it does not make sense to have a reply threads if the 
> annotation users comment on changes all the time.

In a system where the annotation status properties are critically 
important (e.g., if someone is using status=Completed to track work that 
is done), I would expect the Annotea server to restrict who can make 
which changes to the status property.  In other scenarios where things 
are more open (think Wiki instead of formal work flow), people might be 
able to rely on each other to just do the right thing.  And a server 
could allow people to change the status property but not allow them to 
change the body or other properties of an annotation (so that reply 
threads would continue to make sense).


> Use annotation types kind of mechanism:
> 
> With Annotea annotations we have annotation types. We wanted users to be 
> able to define what types they want to use so there is actually a way to 
> define and use your own types: 
> http://www.w3.org/2001/Annotea/User/Types.html. Unfortunately, we did 
> not have resources to experiment more with these. But basically right 
> now I could define annotations with the status types that people are 
> listing here.

I am not 100% sure how the annotation types are intended to be used. 
Can one annotation have many types (many different r:type properties)? 
I don't think RDF imposes any limit, but I have been assuming that each 
annotation would have one annotationType (is that wrong?  can an 
annotation be both a Question and a Comment?)  I did think about 
modeling the status concept using types, but it did not seem like quite 
the right fit to me.


> If we think of this from the user point of view a status annotation is 
> clearly not enough. The user can annotate resources including the 
> annotations and replies with a status annotation but they also need to 
> see the current status. There are also many collaborators who can do 
> status changes, we maybe need to define somewhere whose status info we 
> want to subscribe and quite possibly it is different from the subscribed 
> annotations.

For the use cases I have in mind I would expect a group of people to be 
working together in such a way that the status tends to be an agreed 
upon value.  In other words, it is unlikely that two different people 
will have two different ideas of what the status should be.  For 
example, suppose three scientists are working together on a paper and 
Scientist1 notices that a graph is missing in one spot.  She might 
create an annotation that says "Add chart here" and set the status to 
"NeedsAction."  There could be several replies to the original 
annotation (e.g., to clarify what the chart should look like), but the 
status remains "NeedsAction" until one of the scientists takes on the 
task and completes it.  When that person has added the chart, he or she 
would set the status to Completed.  Optionally, the original creator of 
the annotation (Scientist1) could set the status to "Approved" after she 
has verified that the work was done to her satisfaction.


> Misc. thoughts:
> 
> For ui we need to define an order for the statuses. So it is possible to 
> help the user to select the next/some previous state. We may want to 
> show the thread of the status changes. We need to maybe have a summary 
> view where all these annotations are gathered together so it looks a bit 
> like bugzilla view.

Summary views are a good idea, and I suspect we will eventually want to 
extend Annotea to support them better.  I also agree that the 
specification should provide advice about the likely transitions that 
state values will go through, but I do not think it should disallow 
unusual transitions (e.g., people need to be allowed to fix mistakes).


> How do we handle the versions of the resource we are changing? If the 
> versions are not available maybe some annotations start to have status 
> obsolete and wither away. But really it would be nice to have some cvs 
> versions with annotations and some of them are copied to new versions 
> and some are not because they have a certain status.

In general it is hard to know whether a particular (older) annotation is 
obsolete.  If the resource has changed since the annotation was made, 
the annotation may be obsolete... or it may not be.  But allowing for 
status=obsolete may be useful (I have not thought about it a lot yet).


> Also status topics may be used for grouping annotations and other 
> resources. How to visualize the status and record the changes in that 
> case? Are some topics visualized differently than others?

I do not understand your point here.  Can you provide an example?


> I think your design is a good start and I hope these thoughs help to go 
> forward.

Thank you for your detailed comments and ideas.

-Mark

Received on Monday, 21 March 2005 19:04:36 UTC