the task issue
Henry Story
comments one by one as they occur to me, so that we can have different
threads going on the subject.
:Task a owl:Class;
rdfs:subClassOf :Issue ;
:ewlNote "There is an ongoing discussion on whether this class
should be a sub or superclass of Issue, or if we could just use
wf:Task. However, most issue trackers uses Task as a subClass of an
issue, as a task that needs to be executed. This differs from other
issues such as Bug and Enhancement. A Bug needs to be resolved, but
the actual Task that needs to be executed could perhaps just be to
mark it as a duplicate. An Enhancement is something that could be
implemented or perhaps rejected. Hence we need to express this use of
Task in the issue trackers in Baetle. I'm leaning towards keeping this
as a special subClassOf Issue. We should keep Issue as subClassOf
wf:Task though as the wf:state property is very useful."@en;
.
A few remarks:
"However, most issue trackers uses Task as a subClass of an issue,"
How do you determine that? No issue tracker as far as I know has an
ontology for their vocabulary. You must be reverse engineering their
ontology to make such a statement. Could you provide an example (with
a URL) of an issue that you feel led you to make that statement.
We would need to look at different ways that issue could be modeled.
Perhaps your answer is correct, but it would be good to have some
cases to help decide the issue.
If you look at the wf:Task 'ontology', you can see that it allows a
Task to go through a number of different states.
Erling Wegger Linde
On Sat, May 31, 2008 at 6:33 AM, Henry Story <henry...@gmail.com> wrote:
> Thanks Linde for the new N3 version of the ontology. I will write out
> comments one by one as they occur to me, so that we can have different
> threads going on the subject.
>
> :Task a owl:Class;
> rdfs:subClassOf :Issue ;
> :ewlNote "There is an ongoing discussion on whether this class should be
> a sub or superclass of Issue, or if we could just use wf:Task. However, most
> issue trackers uses Task as a subClass of an issue, as a task that needs to
> be executed. This differs from other issues such as Bug and Enhancement. A
> Bug needs to be resolved, but the actual Task that needs to be executed
> could perhaps just be to mark it as a duplicate. An Enhancement is something
> that could be implemented or perhaps rejected. Hence we need to express this
> use of Task in the issue trackers in Baetle. I'm leaning towards keeping
> this as a special subClassOf Issue. We should keep Issue as subClassOf
> wf:Task though as the wf:state property is very useful."@en;
> .
>
> A few remarks:
>
> "However, most issue trackers uses Task as a subClass of an issue,"
>
> How do you determine that? No issue tracker as far as I know has an ontology
> for their vocabulary. You must be reverse engineering their ontology to make
> such a statement. Could you provide an example (with a URL) of an issue that
> you feel led you to make that statement.
Well, I have struggled to decide on this topic. But my argument is
more based on that if you call a tool an issue tracker, e.g. Jira,
then the concepts like Defect, Improvement and Task would then be
subclasses of Issue..? I'm not sure if that is a very correct
assumption to make, but that is how I have thought about it.
To give you an example I found this one:
http://trac.edgewall.org/ticket/4163, If you look at the first
changeset/comment you can see that this "Issue" was reported in as a
Defect, but was then changed to a Task (because there was a concrete
action that had to be taken). If Defect had been a subclass of Task,
would this "Issue" had needed to change from Defect to Task then? Of
course my reasoning here are based on how a user actually uses the
issue tracker, so I'm not sure if that is sufficient proof..? What do
you think?
>
> We would need to look at different ways that issue could be modeled. Perhaps
> your answer is correct, but it would be good to have some cases to help
> decide the issue.
>
> If you look at the wf:Task 'ontology', you can see that it allows a Task to
> go through a number of different states.
>
>
>
>
>
> see: http://code.google.com/p/baetle/wiki/WorkFlowOntology
>
> So to take your initial examples
>
> "A Bug needs to be resolved, but the actual Task that needs to be executed
> could perhaps just be to mark it as a duplicate."
>
> I don't think you are using the word 'Task' the same way as the WorkFlow
> Ontology is.
> (Which is why it is nice to use URIs to identify concepts, so we can
> distinguish different ones) This is not such a problem. The WorkFlow
> ontology is sketchy and seems to
I think I referred to why a baetle:Bug was different from a
baetle:Task. And why baetle:Task should be a subclass of baetle:Issue.
>
> There are some interesting examples to help understand the task ontology
> here:
>
> http://www.w3.org/2005/01/wf/test/foo.n3
>
> # so we could write out task ontology out like this
>
> btl:Bug rdfs:subClassOf wf:Task;> #to be closer to owl:dl (does this mess things up?)
> rdfs:label "a bug" .
>
>
> #next we define the states a bug can be in.
> #now we create some specialised states
> #here I just copy from the example foo.n3 above
>
> #I replace the rdfs:instanceOf with rdfs:subClassOf here
> #to be closer to owl:dl (does this mess things up?)
>
> btl:Submital rdfs:subClassOf wf:State;
> rdfs:label "submitted bug";
> wf:allowedTransitions ( btl:acceptance btl:rejection btl:duplicate).
>
> btl:Rejected rdfs:subClassOf wf:TerminalState;
> rdfs:label "rejected".
>
> btl:Accepted rdfs:subClassOf wf:State;
> rdfs:label "accepted";
> wf:allowedTransitions (btl:delegation btl:assignment btl:closure).
>
> btl:Pending rdfs:subClassOf wf:State;
> s:label "pending";
> wf:allowedTransitions (btl:reacceptance btl:closure);
> rdfs:comment "Pending means waiting for someone outside the group.".
>
> btl:OpenAction rdfs:subClassOf wf:State;
> rdfs:label "open action";
> wf:allowedTransitions (foo:reacceptance foo:closure).
>
> btl:Closed a wf:TerminalState;
> s:label "closed".
>
I think this is a good idea. However, I think it is important that we
don't leave any state (actually often a combination of status +
resolution) that any issue tracker uses out. What I mean is that it is
important that when you translate an Issue to baetle it should be
possible to translate it back with all the same attributes. This is
why I moved baetle:Fixed, baetle:WorksForMe etc. up as subclasses of
wf:State. So that they could be combined with both baetle:Closed and
baetle:Resolved. However, by adding wf:allowedTransitions I think this
will be very complex? Maybe we should separate "Status" and
"Resolution" in baetle too? (Add a class baetle:Resolution with
baetle:Fixed, baetle:WorksForMe etc. as subclasses and readd the
property baetle:resolution) What do you think?
> #
> # see foo.n3 for examples definitions of those properties
> #
>
>
> Now when someone submits a bug we can add the following http://www.w3.org/2005/01/wf/test/foo.n3
>
> :bug1 a wf:Task;
> wf:state bg:Submitted .
>
> Now I think it says in
> http://www.w3.org/2005/01/wf/flow.n3
> (admittedly a very sketchy ontology) that
>
> [[
> wf:state a rdf:Property;
> rdfs:label "state";
> rdfs:subClassOf rdf:type; # or equivalentTo?
> rdfs:domain Task;
> rdfs:range State.
> ]]
>
> Now I think it should have been "rdfs:subPropertyOf" above. The idea being
> that
> a Task is a state. (I find some of this tricky to interpret). That seems to
> make things
> more complicated so perhaps we had better ignore that for the moment.)
If the wf ontology is kind of sketchy, should we try to improve it? Or
should we use another? Is it being used by others?
>
> :bug1 wf:state [ = xxx:submitted;
> a btl:Submittal ] .
>
Yeah, I think then when the bug gets accepted it should just change to
:bug1 wf:state [ a btl:Accepted ] .
Btw. if baetle:Dupcliate a wf:State shouldn't this be
connected/combined with the baetle:duplicate property somehow? I
realize that this could complicate things even further, but if an
issue has a baetle:duplicate with owl:someValuesFrom baetle:Issue,
should we add a restriction so that its wf:state is baetle:Duplicate?
> perhaps later then the bug gets accepted
>
> Now I don't quite understand right now how wf:Transitions are meant to work.
> There is something hidden in those rules that I am having difficulty
> figuring out at this time...I'm not sureI'm not sure
>
> we need to work out how one can transition between different states, and how
> these are related to a task....
>
> Henry
>
>
>
>
- Erling
--
Med vennlig hilsen
Erling Wegger Linde
--
Med vennlig hilsen
Erling Wegger Linde
Henry Story
Just stating that would be a very weak argument.
Btw, we are not building an issue tracker. We are trying to describe
issues, how they relate to source code, version control, tasks etc,
etc... Of course this should be useful in helping version control
systems cooperate. But we should not think that the issue tracker is
fundamental. There will be many other uses of this vocabulary.
Anyway....
> To give you an example I found this one:
> http://trac.edgewall.org/ticket/4163, If you look at the first
> changeset/comment you can see that this "Issue" was reported in as a
> Defect, but was then changed to a Task (because there was a concrete
> action that had to be taken). If Defect had been a subclass of Task,
> would this "Issue" had needed to change from Defect to Task then? Of
> course my reasoning here are based on how a user actually uses the
> issue tracker, so I'm not sure if that is sufficient proof..? What do
> you think?
Thanks for the example. That is very useful.
Yes, I see that the change history of that ticket has the following
lines "type changed from defect to task". I can also see that that is
a good informal way of describing things.
As a matter of interest this could mean a bunch of things. Here are a
few I can think of:
1- As you interpret it, a ticket can be of different types, a la
rdf:type at different times
2- They are using the english word "type" in a different way than
the set theoretic way used by rdfs. Perhaps it is a shorthand for some
thing more complex. After all it is meant for human readers whereas
RDF is trying to make things useable by computers.
One way of seeing the plausibility of 2, is to think how a
programmer would have implemented something like it in most OO
programming languages, Java for example. As those languages make it
difficult to add new superclasses to an object, at run time, the
programmer would probably have a Ticket class and then a method on
that to return the type, perhaps something like
class Ticket {
ActionType getType();
void setType(ActionType at);
...
}
However the programmer did it, it very likely was done some way that
has very little to do with the english text, and that the two were
written by people with very little knowledge of each other's work.
One thing it has done is make me wonder if a baetle:Issue should be a
subclass of a Task....
To decide we would have to see what advantages we can get from putting
things this way.
[I am just about to board a plane from San Francisco to Paris. So I'll
make my answers shorter below]
>> [snip]
>> So to take your initial examples
>>
>> "A Bug needs to be resolved, but the actual Task that needs to be
>> executed
>> could perhaps just be to mark it as a duplicate."
>>
>> I don't think you are using the word 'Task' the same way as the
>> WorkFlow
>> Ontology is.
>> (Which is why it is nice to use URIs to identify concepts, so we can
>> distinguish different ones) This is not such a problem. The WorkFlow
>> ontology is sketchy and seems to
>
> I think I referred to why a baetle:Bug was different from a
> baetle:Task. And why baetle:Task should be a subclass of baetle:Issue.
Ok. :-) Now we have to work out what the difference is between a
wf:Task and a baetle:Task.
I think long term we should aim for that. But given the flexibility of
RDF and it's use of the open world assumption, we don't need to fill
in all the details immediately. Those can always be added later. I
think we should rather try to sketch a few bugs from a few issue
trackers we understand and see how far we can get. Then extend our
knowlege from that.
> What I mean is that it is
> important that when you translate an Issue to baetle it should be
> possible to translate it back with all the same attributes.
We want to be able to model things well. But we don't need to solve
every issue tracker problem either. We just need to make sure they can
build their vocabulary on it.
> This is
> why I moved baetle:Fixed, baetle:WorksForMe etc. up as subclasses of
> wf:State. So that they could be combined with both baetle:Closed and
> baetle:Resolved. However, by adding wf:allowedTransitions I think this
> will be very complex? Maybe we should separate "Status" and
> "Resolution" in baetle too? (Add a class baetle:Resolution with
> baetle:Fixed, baetle:WorksForMe etc. as subclasses and readd the
> property baetle:resolution) What do you think?
Yes, it may be too complex. The point was to have some way to help
delineate the space we are working in. If one makes something too
disconnected from other things it becomes difficult to understand the
space one is working in. The WorkFlow ontology was helpful to refer
to. If we can find a later version, better version.
Ok I'll look at that later. I have to fly now...
Henry
Erling Wegger Linde
Yes, I can agree with that, probably why I find it hard to take a
final stand on this issue.
>
> Btw, we are not building an issue tracker. We are trying to describe
> issues, how they relate to source code, version control, tasks etc,
> etc... Of course this should be useful in helping version control
> systems cooperate. But we should not think that the issue tracker is
> fundamental. There will be many other uses of this vocabulary.
I agree.
>
> Anyway....
>
>> To give you an example I found this one:
>> http://trac.edgewall.org/ticket/4163, If you look at the first
>> changeset/comment you can see that this "Issue" was reported in as a
>> Defect, but was then changed to a Task (because there was a concrete
>> action that had to be taken). If Defect had been a subclass of Task,
>> would this "Issue" had needed to change from Defect to Task then? Of
>> course my reasoning here are based on how a user actually uses the
>> issue tracker, so I'm not sure if that is sufficient proof..? What do
>> you think?
>
> Thanks for the example. That is very useful.
>
> Yes, I see that the change history of that ticket has the following
> lines "type changed from defect to task". I can also see that that is
> a good informal way of describing things.
>
> As a matter of interest this could mean a bunch of things. Here are a
> few I can think of:
>think it is important that potential users of baetle (experienced with RDF of not) should not get the impression that baetle is to limited for their use.
> 1- As you interpret it, a ticket can be of different types, a la
> rdf:type at different times
> 2- They are using the english word "type" in a different way than
> the set theoretic way used by rdfs. Perhaps it is a shorthand for some
> thing more complex. After all it is meant for human readers whereas
> RDF is trying to make things useable by computers.
>
> One way of seeing the plausibility of 2, is treachedo think how a
> programmer would have implemented something like it in most OO
> programming languages, Java for example. As those languages make it
> difficult to add new superclasses to an object, at run time, the
> programmer would probably have a Ticket class and then a method on
> that to return the type, perhaps something like
>
> class Ticket {
>
> ActionType getType();
> void setType(ActionType at);
> ...
> }
>
>
> However the programmer did it, it very likely was done some way that
> has very little to do with the english text, and that the two were
> written by people with very little knowledge of each other's work.
>
> One thing it has done is make me wonder if a baetle:Issue should be a
> subclass of a Task....
> To decide we would have to see what advantages we can get from putting
> things this way.
>.
> [I am just about to board a plane from San Francisco to Paris. So I'll
> make my answers shorter below]
>
>>> [snip]reachedreached
>>> So to take your initial examples
>>>
>>> "A Bug needs to be resolved, but the actureachedal Task that needs to be
>>> executed
>>> could perhaps just be to mark it as a duplicate."
>>>
>>> I don't think you are using the word. 'Task' the same way as the
>>> WorkFlow
>>> Ontology is.reached
>>> (Which is why it is nice to use URIs to identify concepts, so we can
>>> distinguish different ones) This is not such a problem. The WorkFlow
>>> ontology is sketchy and seems to
>>
>> I think I referred to why a baetle:Bug was different from a
>> baetle:Task. And why baetle:Task should be a subclass of baetle:Issue.
>
> Ok. :-) Now we have to work out what the difference is between a
> wf:Task and a baetle:Task.
>
Maybe a wf:Task is a very generic Task that can be almost anything,
e.g. "Climb a mountain" or "Drive a boat". I think we want a machine
to understand the difference between a baetle:Task and a wf:Task in
such a way that a baetle:Task is more limited in scope, i.e. related
to the production/maintenance of software. Do you agree?
I see your point here.
>
>> What I mean is that it is
>> important that when you translate an Issue to baetle it should be
>> possible to translate it back with all the same attributes.
>
> We want to be able to model things well. But we don't need to solve
> every issue tracker problem either. We just need to make sure they can
> build their vocabulary on it.
>
>> This is
>> why I moved baetle:Fixed, baetle:WorksForMe etc. up as subclasses of
>> wf:State. So that they could be combined with both baetle:Closed and
>> baetle:Resolved. However, by adding wf:allowedTransitions I think this
>> will be very complex? Maybe we should separate "Status" and
>> "Resolution" in baetle too? (Add a class baetle:Resolution with
>> baetle:Fixed, baetle:WorksForMe etc. as subclasses and readd the
>> property baetle:resolution) What do you think?
>
> Yes, it may be too complex. The point was to have some way to help
> delineate the space we are working in. If one makes something too
> disconnected from other things it becomes difficult to understand the
> space one is working in. The WorkFlow ontology was helpful to refer
> to. If we can find a later version, better version.
>
> Ok I'll look at that later. I have to fly now...
Hope you got to your plane in time =)
- Erling
>
> Henry
Henry Story
On 1 Jun 2008, at 14:38, Erling Wegger Linde wrote:
>>
>> Ok. :-) Now we have to work out what the difference is between a
>> wf:Task and a baetle:Task.
>>
>
> Maybe a wf:Task is a very generic Task that can be almost anything,
> e.g. "Climb a mountain" or "Drive a boat". I think we want a machine
> to understand the difference between a baetle:Task and a wf:Task in
> such a way that a baetle:Task is more limited in scope, i.e. related
> to the production/maintenance of software. Do you agree?
Yes, one could do that. But it just seems a little arbitrary to me.
Furthermore bug tracking systems may not just be about tracking bugs
in software, but could be about tracking bugs in any system. Now we
don't want to make it an absolute rule that we need to be able to deal
with any bug tracking system, but we should not arbitrary limit
ourselves if possible.
Limitations should flow of logical necessity: specifying classes and
relations in OWL leads to a number of consequences. (see "Semantic
Web for the Working Ontologist") These consequences will structure
what we are saying and limit it.
If I look at
http://trac.edgewall.org/ticket/4163
I don't think that they are limiting their notion of a task to a
software task either. My guess is that they are thinking of a ticket
as some piece of paper that can be put into different drawers. One of
these drawers is named "defect", the other is named "task". Different
processes feed on tickets in each of the drawers. Perhaps when it is
in the "defect" drawer a ticket is assigned to some group that checks
the validity of that issue, and then assigns it to someone as a task.
So yes, here the notion of a task is something like: "this has been
checked, and we agree it's an issue, and so we can pass it on to
someone as a task". Perhaps it is that. Perhaps not.
We certainly don't want to have an ontology that makes complex
distinctions at this level of detail. I would be surprised even if the
trac software has much to say about such distinctions. Each project
using the trac software will probably build its own ticket management
on top of trac, and fit it into its own workflow one way or the other.
So perhaps instead of baetle:Task we should create the notion of
trac:Task , which would be the sense of Task given by the trac system,
as shown by the ticket 4163 above.
The trac system could then define what the states a trac:Task can be
in and for each of these wf:States what their allowed transitions are.
IMPORTANT:
Even so this is making me question whether baetle:Issue should be a
subclass of wf:Task.
First of all we would need to decide if a baetle:Issue may not be a
lot more like a doc:Work than a wf:Task. In some sense an issue report
is what starts a task or sequence of tasks. Also there are a lot of
properties of an issue that are very documentish, such as "title",
"modified", ... Perhaps the idea of a "ticket" is not so bad, in that
it reveals the document nature of an an issue.
But perhaps the relation between a document and an issue is very
similar to the relation between a foaf:Document and a foaf:Person,
namely
<> a foaf:Document;
foaf:primaryTopic <#issue> .
<#issue> a baetle:Issue .
Perhaps we should even create a subclass of foaf:Document, in the same
way foaf creates the foaf:PersonalProfileDocument namely
baetle:Ticket rdfs:subClassOf foaf:Document;
rdfs:comment "a document that has a primaryTopic that is a
baetle:Issue" .
This would then allow us to divide the properties currently on
baetle:Issue into those with domain of baetle:Ticket and those with
domain of foaf:Document.
With that in mind, perhaps we can then still allow a baetle:Issue to
be a subclass of a foaf:Task. But now we would understand the creation
of an issue to be first the putting together of a baetle:Ticket with
enough information that it creates a baetle:Issue. So the discussion
around a baetle:Ticket is the discussion that leads to the discovery
of a beatl:Issue.
Does this make more sense? I wonder how far this brings us...
Henry
Erling Wegger Linde
I think this makes sense. It would be nice to say that a baetle:Ticket
is more like a document, that describes or refers to a baetle:Issue or
a wf:Task. I'm not sure what the scope of a baetle:Ticket actually
would be then, I guess all kinds of projects could use them, software
or not, but perhaps it is even broader? Even so, I think baetle:Ticket
would be more specific than a wf:Task. I think that would be a very
nice feature. Let's say you want issue a SPARQL query against a triple
store containing all your company's data. I think then it would be
valuable to separate wf:Tasks that are related to baetle:Tickets from
just every other potential wf:Task. Do you agree? Or I am thinking
withing the bounds of traditional issue trackers again?
So if you have a baetle:Ticket that describes or refers to a wf:Task,
then a computer should probably interpret this like: "This is a
baetle:Ticket which is a document that was created to keep track on
something that is related to a project (?) and since this
baetle:Ticket refers to a wf:Task (which can be anything) that Task
may be have to carried out or otherwise rejected as a mean to keep the
project progressing?? (the latter is maybe a conclusion that goes a
bit too far?)"
But taking this further, I'm starting to doubt whether a baetle:Issue
(or more specific baetle:Bug or baetle:Enchancement) should be
subclasses of wf:Task too. A description of a baetle:Bug is very
different from the action (read wf:Task) that has to be taken to solve
it (?). But again, a baetle:Bug certainly could use the wf:State
property (so maybe it is a subclass of wf:Task after all?).
This brings up the issue of where to put the state (or status +
resolution). A baetle:Bug described or referred to by a baetle:Ticket
could probably have used the states Fixed, WontFix, Resolved etc. A
baetle:Task probably wouldn't use Fixed(?) but certainly Started,
Closed (or perhaps Finished is better?). A baetle:Ticket however could
probably use New, Unconfirmed etc.
So maybe some states should go to wf:Task and baetle:Issue whether or
not a baetle:Issue is a subClassOf wf:Task. And some states should go
on the baetle:Ticket? Hopefully without making baetle:Ticket a
wf:Task!
I feel like writing out a few examples here to illustrate this:
#Example 1:
<> a baetle:Ticket ;
foaf:primaryTopic <#issue> ;
baetle:ticketState "Unconfirmed" .
<#issue> a baetle:Issue ;
wf:state [ a baetle:NotReproducible ] .
#Example 2:
<> a baetle:Ticket ;
foaf:primaryTopic <#task> ;
baetle:ticketState "Confirmed" .
<#task> a wf:Task ;
wf:state [ a baetle:Started ] .
As you see from Example 1 and 2, I have used baetle:ticketState (which
could be wf:state?) and wf:state to indicate two states on the
combination of a baetle:Ticket and a baetle:Issue or wf:Task. I think
this might be a better solution than using the "multiple inheritance"
approach I have suggested earlier in order to be able to express both
the "status" and "resolution" that many issue trackers use. I'm not
quite sure about if it is enough, but it may seem like it. An
interesting thing is that I think some states that traditionally
belongs to the "resolution" attribute like baetle:Duplicate should
belong to the baetle:Ticket, while another "resolution"; baetle:Fixed
fits better as a wf:State on a baetle:Issue. Hence with need to figure
out which goes where, but I do think it would be a good approach to
add certain states to the baetle:Ticket and other states (or
resolutions..) to the baetle:Issues and wf:Tasks. Does this make sense
to you?
> Henry
>
> >
>
Henry Story
On 2 Jun 2008, at 14:00, Erling Wegger Linde wrote:
> I think this makes sense. It would be nice to say that a baetle:Ticket
> is more like a document, that describes or refers to a baetle:Issue or
> a wf:Task. I'm not sure what the scope of a baetle:Ticket actually
> would be then, I guess all kinds of projects could use them, software
> or not, but perhaps it is even broader?
Well currently I am thinking they are very different. A ticket is a
document, an Issue or Bug or enhancement is something else. This would
be parallel to a foaf:PersonalProfileDocument and a foaf:Person. So we
should be able to say
btl:Ticket owl:disjointWith btl:Issue, btl:Bug .
Now what is a bug or an issue, that it is different from a document?
It is true that if we are correct in making such a distinction here,
it is not as evident as the distinction between a foaf:Document and a
foaf:Person.
Well, we should be able to say at least that a document is something
that has an interpretation, a log:semantics.
( @prefix log: <http://www.w3.org/2000/10/swap/log#> )
One might argue that a Bug or an Issue does not have that.
I am talking about a btl:Bug here because my intuitions on a bug are
much clearer.
A Bug is something that can be fixed, that somehow relates a machinery
(software) and a specification, and states that the thing is not
following the spec. The thing is not functioning as it should. So we
have the notion of how a thing SHOULD function, and how it does. It is
of course a lot clearer if the way something SHOULD function is
specified by a specification (document).
From this it would follow that you are right that a bug is not yet a
task, though it is usually the cause of a number of tasks: either to
change the spec, or to change the software.
Now the fact that we use the word "should" indicates that we are
dealing with a counterfactual notion. David Lewis defines "would" this
way
if S1 were the case S2 would be the case
iff in the closest possible worlds where S1 is the case S2 is the case.
similarly in another paper I don't have handy here, David Lewis
defines should similarly but with the extra notion of the best closest
possible worlds, where best is defined relative to an agent. Now
documents are ways of specifying possible worlds, and spec documents
are usually used to describe the correct behavior (good behavior) of a
piece of machinery.
It is now clear why a bug leads to a task since one should do what is
best...
So perhaps we have for a bug the following
:bug a btl:Bug;
btl:spec <wiki/spec2>;
btl:test <bug/testcode>;
btl:fix <svn/checkin22/> .
That seems a little too precise, but it will do for an example.
> Even so, I think baetle:Ticket
> would be more specific than a wf:Task. I think that would be a very
> nice feature. Let's say you want issue a SPARQL query against a triple
> store containing all your company's data. I think then it would be
> valuable to separate wf:Tasks that are related to baetle:Tickets from
> just every other potential wf:Task. Do you agree? Or I am thinking
> within the bounds of traditional issue trackers again?
Could be useful...
>
> So if you have a baetle:Ticket that describes or refers to a wf:Task,
> then a computer should probably interpret this like: "This is a
> baetle:Ticket which is a document that was created to keep track on
> something that is related to a project (?) and since this
> baetle:Ticket refers to a wf:Task (which can be anything) that Task
> may be have to carried out or otherwise rejected as a mean to keep the
> project progressing?? (the latter is maybe a conclusion that goes a
> bit too far?)"
>
> But taking this further, I'm starting to doubt whether a baetle:Issue
> (or more specific baetle:Bug or baetle:Enchancement) should be
> subclasses of wf:Task too.
I think I agree on this too.
> A description of a baetle:Bug is very
> different from the action (read wf:Task) that has to be taken to solve
> it (?). But again, a baetle:Bug certainly could use the wf:State
> property (so maybe it is a subclass of wf:Task after all?).
Well perhaps we have a number of processes
1- a ticket starts a process of determining if the ticket is valid:
+ is this ticket a bug ticket, a todo ticket,
+ what is the bug really about?
+ can it be reproduced...
2- this then starts the process of fixing the bug, and this may
discover yet more bugs...
> This brings up the issue of where to put the state (or status +
> resolution). A baetle:Bug described or referred to by a baetle:Ticket
> could probably have used the states Fixed, WontFix, Resolved etc.
yes.
> A
> baetle:Task probably wouldn't use Fixed(?) but certainly Started,
> Closed (or perhaps Finished is better?).
yes
> A baetle:Ticket however could
> probably use New, Unconfirmed etc.
yes.
> So maybe some states should go to wf:Task and baetle:Issue whether or
> not a baetle:Issue is a subClassOf wf:Task. And some states should go
> on the baetle:Ticket? Hopefully without making baetle:Ticket a
> wf:Task!
Yes I think we have tickets that create tasks,
and Bugs that create other tasks,
where bugs and tickets are not themselves tasks.
>
> I feel like writing out a few examples here to illustrate this:
>
> #Example 1:
> <> a baetle:Ticket ;
> foaf:primaryTopic <#issue> ;
> baetle:ticketState "Unconfirmed" .
>
> <#issue> a baetle:Issue ;
> wf:state [ a baetle:NotReproducible ] .
<> a btl:Ticket;
foaf:primaryTopic <#bug> ;
btl:ticketTask </ticket/task#it> .
<#bug> a btl:Bug;
btl:spec <wiki/spec2>;
btl:test <bug/testcode>;
btl:task [ a wf:Task; ...] .
Here the ticket Task would be the task to verify the ticket, and it
would go through different states. Perhaps this would be to create a
minimally complete bug definition, agree on it, and set a value to it.
So here I am separating the ticket, the bug and the tasks associated
with them.
But perhaps one could have some shortcut relations between a ticket
and the state of its task...
> #Example 2:
> <> a baetle:Ticket ;
> foaf:primaryTopic <#task> ;
> baetle:ticketState "Confirmed" .
>
> <#task> a wf:Task ;
> wf:state [ a baetle:Started ] .
>
> As you see from Example 1 and 2, I have used baetle:ticketState (which
> could be wf:state?) and wf:state to indicate two states on the
> combination of a baetle:Ticket and a baetle:Issue or wf:Task. I think
> this might be a better solution than using the "multiple inheritance"
> approach I have suggested earlier in order to be able to express both
> the "status" and "resolution" that many issue trackers use. I'm not
> quite sure about if it is enough, but it may seem like it. An
> interesting thing is that I think some states that traditionally
> belongs to the "resolution" attribute like baetle:Duplicate should
> belong to the baetle:Ticket, while another "resolution"; baetle:Fixed
> fits better as a wf:State on a baetle:Issue. Hence with need to figure
> out which goes where, but I do think it would be a good approach to
> add certain states to the baetle:Ticket and other states (or
> resolutions..) to the baetle:Issues and wf:Tasks. Does this make sense
> to you?
yes it makes sense. Though here I have gone one further and clearly
differentiated the ticket, the bug, and the workflows that stem from
all of them. Perhaps we are making things too complicated now, but if
it helps us think about things that could be helpful in and of itself.
Henry
Erling Wegger Linde
A relation to a spec would be great! But do you think of a
requirements specification/user story or the description/summary of an
issue? I think both would be great, but we should probably separate
them?
So btl:Ticket, btl:Issue and wf:Task all have states. I agree. But
should we then use wf:state on these? Probably not since wf:state has
"domain Task;"?
Then we need something like btl:ticketState and btl:issueState?
>
>
>> This brings up the issue of where to put the state (or status +
>> resolution). A baetle:Bug described or referred to by a baetle:Ticket
>> could probably have used the states Fixed, WontFix, Resolved etc.
>
> yes.
>
>> A
>> baetle:Task probably wouldn't use Fixed(?) but certainly Started,
>> Closed (or perhaps Finished is better?).
>
> yes
>
>> A baetle:Ticket however could
>> probably use New, Unconfirmed etc.
>
> yes.
>
>> So maybe some states should go to wf:Task and baetle:Issue whether or
>> not a baetle:Issue is a subClassOf wf:Task. And some states should go
>> on the baetle:Ticket? Hopefully without making baetle:Ticket a
>> wf:Task!
>
> Yes I think we have tickets that create tasks,
> and Bugs that create other tasks,
> where bugs and tickets are not themselves tasks.
I think that is a great classification/description.
>
>>
>> I feel like writing out a few examples here to illustrate this:
>>
>> #Example 1:
>> <> a baetle:Ticket ;
>> foaf:primaryTopic <#issue> ;
>> baetle:ticketState "Unconfirmed" .
>>
>> <#issue> a baetle:Issue ;
>> wf:state [ a baetle:NotReproducible ] .
>
> <> a btl:Ticket;
> foaf:primaryTopic <#bug> ;
> btl:ticketTask </ticket/task#it> .
>
> <#bug> a btl:Bug;
> btl:spec <wiki/spec2>;
> btl:test <bug/testcode>;
> btl:task [ a wf:Task; ...] .
>
> Here the ticket Task would be the task to verify the ticket, and it
> would go through different states.
Ok, so the it is the TicketTask that holds the state for the Ticket? I
think maybe that is a bit too complex? Maybe the Ticket should just
have a btl:ticketState directly?
>Perhaps this would be to create a
> minimally complete bug definition, agree on it, and set a value to it.
>
> So here I am separating the ticket, the bug and the tasks associated
> with them.
> But perhaps one could have some shortcut relations between a ticket
> and the state of its task...
Yes, sometimes I think baetle:Tickets can refer to wf:Tasks directly.
I think your examples/suggestions are great, apart from the comment I
made above that maybe a btl:Ticket should have a btl:ticketState
(leave out the btl:ticketTask for now).
Henry Story
ontology, which he told me on #swig he would do by the end of this
week, to see what light that sheds on these issues.
Henry
Erling Wegger Linde
--
Henry Story
looks like the bug I reported
http://chatlogs.planetrdf.com/swig/2008-05-31.html
is now fixed in this version
http://www.w3.org/2005/01/wf/flow.n3
We now have
state a rdf:Property;
s:label "state";
s:subPropertyOf rdf:type; # or equivalentTo?
s:domain Task;
s:range State.
Whilst I don't think a lot of energy is going to go into this, it is
good to see that we can get some feedback from there. This will make
comparing the two ontologies easier.
Henry
Erling Wegger Linde
>
> Further good news is that the wf ontology is being maintained. It
> looks like the bug I reported
>
> http://chatlogs.planetrdf.com/swig/2008-05-31.html
>
> is now fixed in this version
>
> http://www.w3.org/2005/01/wf/flow.n3
>
> We now have
>
> state a rdf:Property;
> s:label "state";
> s:subPropertyOf rdf:type; # or equivalentTo?
> s:domain Task;
> s:range State.
>
> Whilst I don't think a lot of energy is going to go into this, it is
> good to see that we can get some feedback from there. This will make
> comparing the two ontologies easier.
Great to see that it is fixed!
>
> Henry
>
>
> On 3 Jun 2008, at 13:45, Erling Wegger Linde wrote:
>> Exciting! :D
>>
>> On Tue, Jun 3, 2008 at 1:40 PM, Henry Story <henry...@gmail.com>
>> wrote:
>>>
>>> We should wait for Nadeem Shamir (CCed) to publish his work flow
>>> ontology, which he told me on #swig he would do by the end of this
>>> week, to see what light that sheds on these issues.
>>>
>>> Henry
>>>
>>> On 3 Jun 2008, at 13:11, Erling Wegger Linde wrote:
>>>
>>>> I think your examples/suggestions are great, apart from the
>>>> comment I
>>>> made above that maybe a btl:Ticket should have a btl:ticketState
>>>> (leave out the btl:ticketTask for now).
>>>>
>>>> - Erling
>
> >
>
--
Nadeem Shabir
Rob and I are just working on documenting the ontology, we'll be
publishing it on vocab.org, our aim is to have something up by the end
of the week.
thank you
Nadeem Shabir
Technical Lead
nadeem...@talis.com
tel: +44(0)870 400 5000
fax: +44(0)870 400 5001
mobile: +44(0)77393 38384
msn: kiya...@hotmail.co.uk
blog: http://www.virtualchaos.co.uk/blog/
Erling Wegger Linde
I've been a bit busy lately, and unfortunately I haven't had time to
contribute to baetle. But I'm still eager to some day see a final
version of baetle, as I think it would be of great value. I want to
continue to contribute to baetle, but probably not so often as I did
while I was writing my Master Thesis.
So after reading up on some of the threads it seemed like we stopped
making progress while waiting for the Lifecycle ontology to be
published.
I believe we need to describe the lifecycle of baetle:Bugs etc. so
currently we have three options for how to to this:
1. Use the Workflow ontology
2. Use the Lifecycle ontology
3. Create our own (or maybe find yet another alternative)
It would be good to agree on one of these alternatives so that we
could start making some progress again.
So which should we choose:
1. Workflow ontology
- Simple
- Maintained
- Is it used by anyone ?
2. Lifecycle ontolgoy
- More complex, but this also gives us more possibilities
- Recently released, are you still maintaining it Rob?
- Have anyone started to use it?
3. Create our own
- If no one uses the other ones, maybe they will stop being
maintained, disappear or just add more complexity to baetle..?
- It is nice to relate baetle to such as DC, FOAF and DOAP which are
widely adopted, but what about WF/Lifecycle?
So if I found the right email adress Rob, please tell us a little
about the state of the Lifecycle ontology.
(I have a lot more thoughts regarding baetle, but I think it is wise
to start dealing with one issue at the time for now)
Thanks,
- Erling
Erling Wegger Linde
I'll try to come up with a simple example on how baetle could use your
ontology soon.
Thanks,
- Erling
On Mon, Aug 18, 2008 at 12:00 PM, Rob Styles
<rob.s...@dynamicorange.com> wrote:
> Hey, sorry, replied only to Erling :-(
>
> Hi Erling,
>
> Sorry we've been quiet for a while.
>
> The Lifecycle ontology is published on vocab.org:
>
> http://vocab.org/lifecycle/schema
>
> Any feedback you have on whether or not this works for you guys would be
> great.
>
> The ontology is being used for applications we're building here and we are
> still maintaining it. Should we decide to move to something (we have no
> thoughts at all about doing that) then we would look to pass the maintenance
> to another active user, so you could take it on as your own if that were to
> happen. Lifecycle has been set up with purl urls for that reason.
>
> rob
>
>
>
> On Sun, Aug 17, 2008 at 5:39 PM, Erling Wegger Linde <erli...@gmail.com>
Erling Wegger Linde
<> a btl:Ticket;
foaf:primaryTopic <#bug> ; # Or maybe btl:bug or btl:issue is
better, after all a ticket might have refer to tasks ++ according to
our previous conversations.
btl:ticketState [a btl:Resolved] .
<#bug> a btl:Bug;
btl:issueState [a btl:Fixed] .
btl:ticketState a owl:ObjectProperty;
rdfs:subPropertyOf lifecycle:state;
rdfs:domain btl:Ticket .
btl:issueState a owl:ObjectProperty;
rdfs:subPropertyOf lifecycle:state;
rdfs:domain btl:Bug .
btl:Resolved a owl:Class;
rdfs:subClassOf lifecycle:State .
btl:Started a owl:Class;
rdfs:SubClassOf lifecycle:State ;
lifecycle:possibleTransition [ a lifecycle:Transition ;
lifecycle:resultingState
btl:Resolved ] .
Does this make sense?
On Mon, Aug 18, 2008 at 6:36 PM, Erling Wegger Linde
<erli...@gmail.com> wroteb:
Henry Story
spent a little time right now studying the lifecycle ontology.
It is an interesting idea to distinguish the transition states of a
ticket and a bug. I suppose a bug can turn out to be owl:sameAs
another bug. Whereas the ticket that contains that bug would get
closed. On the other hand it may feel a little like this is
unnecessary duplication of information. This may be somewhat similar
to asking whether one thinks that documents should have states of
being resolved. Not sure I have a final point of view on this yet.
The life cycle ontology has an example that makes use of Actions. So
it would also be interesting to see how that would fit in here, using
a real example.
Henry
Erling Wegger Linde
<rob.s...@dynamicorange.com> wrote:
> That looks great, but you may be able to get it simpler.
>
> you could just use lifecycle:state directly rather than subclassing it
>
> The other thing is that States are intended to be individuals rather than
> subclasses, so
>
> btl:Resolved a owl:Class;
> rdfs:subClassOf lifecycle:State .
>
>
> btl:Resolved a lifecycle:State
Yes, that looks better, thanks =)
>
> rob
>
>
> On Mon, Aug 18, 2008 at 6:00 PM, Erling Wegger Linde <erli...@gmail.com>
Erling Wegger Linde
>
> Yep, the simple example makes sense to me -- but then I have only
> spent a little time right now studying the lifecycle ontology.
>
> It is an interesting idea to distinguish the transition states of a
> ticket and a bug. I suppose a bug can turn out to be owl:sameAs
> another bug. Whereas the ticket that contains that bug would get
> closed. On the other hand it may feel a little like this is
> unnecessary duplication of information. This may be somewhat similar
> to asking whether one thinks that documents should have states of
> being resolved. Not sure I have a final point of view on this yet.
I believe we agreed on this previously, after a long discussion
regarding the difference between a btl:Bug and somens:Task. But I got
the same impression after reading through this thread again that this
may be a bit complex.
However, using a btl:Ticket that can "have" btl:Bugs and somens:Task,
allows us to express their (btl:Bug and somens:Task) "shared"
attributes or the fact that they are somehow used just as different
types of "issues" in many issuetrackers, although they are
semantically different.. At least we should be able to relate both
btl:Bug and somens:Task to a doap:Project. Or would the following make
sense?
btl:Bug a owl:Class;
rdfs:subClassOf btl:Ticket .
btl:Task a owl:Class;
rdfs:subClass of lifecycle:Task, btl:Ticket
But of course, you could report the same bug, or tasks in different
issuetrackers, and even if you could use a btl:duplicate to state that
they are the same later, what happens to the information about who
reported it (if two persons reported it at different issuetrackers) so
maybe the conclusion is that btl:Ticket is a good idea, agree?
In addition I think maybe this can solve the problem of expressing
both the state and the resolution that are used by many issuetrackers.
E.g. an issue/bug can be closed:fixed or resolved:fixed. If you make
closed/resolved states/properties of a btl:Ticket, you can express the
Fixed, Wontfix as properties on the bug itself.. Hmm, if that sounds
reasonable, I'm not quite sure.
>
> The life cycle ontology has an example that makes use of Actions. So
> it would also be interesting to see how that would fit in here, using
> a real example.
<#exampleAction>
a lifecycle:Action;
lifecycle:resource <#Bug>;
lifecycle:task btl:ResolveBug;
lifecycle:taskProgress lifecycle:Started .
One could perhaps reason from this that <#Bug> lifecycle:State [ a
btl:Started ] . ? But that might be a bit too complex?
Or maybe
btl:Resolved a lifecycle:Completed . (or rdfs:subClassOf licecycle:Completed) ?
I guess with the lifecycle ontology we have a lot of options.
- Erling
Erling Wegger Linde
ontology. I also cleaned up some superflous comments etc. inspired
from Uncle Bobs recent book "Clean Code" (I guess there's still some
room for improvent though).
Se http://code.google.com/p/baetle/source/diff?spec=svn194&r=194&format=side&path=/ns/Baetle.ewl.n3&old_path=/ns/Baetle.ewl.n3&old=192
for the diff.
Note that I wasn't able to use instances of lifecycle:State as
suggested by Rob earlier, as I need to express some hierarchy as well
as domain/range constraints on the states, you should see this when
you browse the diff.
- Erling
Erling Wegger Linde
http://code.google.com/p/baetle/wiki/NewExamples
Had to move some properties from btl:Issue to btl:Ticket and also
tried to use dcterms for some properties (updated, created) so I
commited yet another version of Baetle.ewl.n3 today. See the diff
here: http://code.google.com/p/baetle/source/diff?spec=svn199&r=197&format=side&path=/ns/Baetle.ewl.n3&old_path=/ns/Baetle.ewl.n3&old=194
What do you think?
- Erling