Need Ability to Represent a Work Ticket Concept (i.e.; a help desk ticket) #554
Comments
|
@vulnmaster , thank you for posting this. I'm happy to raise this at the October 26th Ontology Committees meeting. It would be helpful if you would be able to present this at that meeting. Please let me know if you haven't received the invitation. I have some follow-on remarks after this, but the end of this fiscal month has become a bit complicated on my end, so I apologize in advance if I trail off for a little while. |
|
I have some questions on what falls into the set of a Work Ticket, asking in part because I'm not familiar with your main exemplar Zendesk. First, let's start with an assumption that the class you're requesting will be called
I ask about those two in particular because they tend to be identified by URLs that could serve as RDF IRIs. And this could help us sketch the scenarios you had provided in English. (And thank you for the examples!) The smartphone processing you suggested could be a supplement to the CASE website's Urgent Evidence narrative. I would like to see a semi-implemented example in the "Competencies Demonstrated" section, sketched in Turtle, JSON-LD to show "This includes something I want to find"; or SPARQL, for "Here's how I would look for something I'm interested Footnotes
|
|
I have a hunch that the requirements might need to be spelled differently. There's a few levels of recursive dependencies suggested in there that I'm not entirely sure we've exercised yet in examples, but there's no reason we can't start now if we haven't. E.g. Requirement 1 suggests ability to tie a ticket to a workflow, which we have two classes that can potentially implement this, Let's assume a workflow similar to what you suggested in Requirement 1:
To me, these are more suggest there are two things to consider: The status of the ticket, and transitions between statuses. Consider especially the last two workflow points, "ticket dispositioned" and "ticket closed". If those are to be "nodes" in a graph, they would look something like this: flowchart LR
Dispositioned -- some work happens --> Closed
I think this means we need to take some care in when we're describing actions (specifically Here is what I think would be a high-level pattern for a ticket workflow of "created," "reviewed", "dispositioned", "closed (finished)", "closed (won't-do)". I think each of those workflow descriptors are actually of flowchart TB
formulating
awaiting_review
awaiting_implementation
completed
left_not_completed
formulating -- Submitted --> awaiting_review
awaiting_review -- Disposition, assign\nfor implementation --> awaiting_implementation
awaiting_implementation -- Request review\nof implementation --> awaiting_review
awaiting_review -- Close, marking\naccomplished --> completed
awaiting_review -- Close, marking\nwon't-do --> left_not_completed
completed -- Reopen --> awaiting_review
left_not_completed -- Reopen --> awaiting_review
With this sketch for reference, or dispute if there's disagreement: What would tie to actions, and what would tie to events? To both branches of that question: As class models, and as external data references? The blocking modeling question I think we're going to have to answer is: How does UCO relate an instance of an |
|
@ajnelson-nist here is my first crack at designing the observable:ActionTicket class and properties. I've added a few other common properties that one might find across ticket management systems. There might be others. { |
|
@ajnelson-nist here is my first crack at a SPARQL query similar to the CASE Investigative personae example but where the query incorporates a search for an ActionTicket where it is in a status of "assigned", and where the other provenance, action, and performer queries are true. Then to order the results by last name and ticketID PREFIX case-investigation: https://ontology.caseontology.org/case/investigation/ SELECT DISTINCT ?lLastName ?ticket ?title ?description ?ticketID ?nOriginalProvenanceRecord ?nInvestigativeAction ?nActionProvenanceRecord ?nPerformer ?nSimpleName FILTER (?nPerformer = ?assignee) |
|
I think there is a design issue with this proposal that digs into UCO's behaviors with respect to time. My concern boils down to the "Observables being independent of observations" matter described in the background of Issue 535. I think because an
... but there are others that change depending on when the ticket is looked at, and those would be better represented as
Before resolution of Issue 535, questions 1 and 2 can be answered with UCO's current design basis, but questions 3--5 can't without wrestling with some base RDF issues like separation of graphs and/or named graphs. (It's possible So, I think these proposed properties can remain as properties, because changing them means you're describing a different object:
But these would be more appropriate as qualities because of their mutability:
If the latter list is retained in this proposal without waiting for Issue 535, UCO should be prepared to adapt them to becoming qualities. I would like to answer this before we vote: How firmly does Meanwhile, I have a few implementation-sketch concerns that are closer to nits:
|
AJN: This patch transcribes a JSON-LD sketch from @vulnmaster . The only change I made was JSON syntax normalization (4-space indentation). Follow-on patches will adapt and integrate content. References: * #554 (comment)
I don't think action:ActionPattern is really relevant here. A sequence of actions that could occur is an action:ActionLifecycle. A workflow of actions such as would exist in any ticketing system would be conveyed as an ActionLifecycle. |
I don't think we need to go anywhere near this level of attempted design at this point. ActionTicket can simply have an ActionTicketStatus property of type string that can be used to track its status. NOTE: For any standardized action names I would strongly propose we use present tense rather than past tense (e.g., Submit rather than Submitted) given that Action exists across the temporal spectrum. |
|
The stab at a draft json-ld ontology above (quote reply trashes all formatting) looks like a pretty good start with a few issues to note.
|
I think you have a valid point here about some of the properties being prone to change over time and having them be direct properties on the object would force either creation of new objects associating provenance back to the old ones with relationships or updating the object directly with some change tracking provenance capability that we have not yet implemented.
I would argue that it must adhere to this principle like all other ObservableObjects. |
|
Re: @sbarnum
I think this would be appropriate given UCO's current implementation.
What about a |
|
Re: @sbarnum
An aside: Since the workflows-as-action-lifecycle discussion might be blocked, we might be better off not blocking this proposal on settling that. |
Background
Ticketing systems are ubiquitous in nearly every organization. They are a primary mechanism that humans (users) use to navigate through a workflow or business process, while documenting actions, relationships, and status updates along the way.
I am fine with my examples in this change proposal being transcribed and credited when others can re-use this content.
As an example, I use a popular ticketing system Zendesk as a primary mechanism to receive requests from cyber domain investigators when they request a tool, specialized data, or have a question that needs to be answered. In my use case, the Zendesk ticket can be created two different ways:
1. Submitting information to a Zendesk bot on my website where the website user provides some basic information: (a) your name - an optional field, (b) email address, and (c) answering "how can we help you" before pressing the send button.
2. Sending an email to support@mysubdomain.zendesk.org - "support" can be tailored to any other string by the Zendesk account administrator
I receive the tickets in the Zendesk dashboard where I then use a customized workflow to advance them to a completed state.
The general ticket fields are:
"Requestor" - with a URL to the name record of the submitter
"Created" - a date time group
"Updated" - a date time group
"Priority" - low, normal, high, or urgent
"Assignee" - a URL to the name record of the assigned person who is responsible for actioning the ticket
"Ticket ID" - an integer (i.e.; 1340)
"Created via" - web, email
"Organization" - a string with the requestor's organization name
"I am interested in" - assignee assigns a classification from a list of strings unique to the organization
"Tags" - assignee assigns one or more tags to further classify this ticket
With this submission I hope to achieve a general concept coverage for a new ObservableObject named something like "ActionTicket" that can represent the generally agreeable fields for work tickets produced by a variety of ticketing systems.
This applies to many use cases encountered within the cyber domain sub disciplines that we are familiar with in the Cyber Domain Ontology Community:
A smart phone arrives as physical evidence to a digital forensics laboratory. It gets processed into the lab's evidence process. Then the phone is assigned via a work ticket to a digital forensic acquisition specialist. That acquisition specialist does the work, then updates the ticket to the next workflow step so that the acquired forensic image can be analyzed.
A cyber threat detection sensor identifies a suspicious event from a high-priority YARA signature. The threat management/investigation product that receives this event from the sensor has a pre-programmed workflow to open up a work ticket so that a human cyber threat analyst can review the event. This human reviews the event in context and moves to disposition the ticket either to incident response or to close it.
These tickets are highly customizable by the administrators and the users of the ticket management system. As an example, here are the fields within a Zendesk ticket. Other ticket management systems may be similar to this but also wildly different. This change request seeks to find the common ground of a basic ticket representation.
Requirements
The ActionTicket concept should represent the basic properties that are found in most vendor ticket standards. A faceting approach could be used so that adopters have flexible to add more properties if desired.
Requirement 1
The ActionTicket should be able to be connected to manual and automated business workflows like: ticket created, ticket submitted, ticket received, ticket reviewed, ticket dispositioned.
Requirement 2
The ActionTicket should be able to be connected to cyber domain events (i.e.; discrete security or business events, intrusion incidents,)
Requirement 3
Added 2023-10-26 during Ontology Committees call
WorkTicket, as an
ObservableObjectsubclass, must adhere to the independence-of-observation principle.Risk / Benefit analysis
The submitter is unaware of risks associated with this change
The benefit of representing an ActionTicket concept should make it possible for developers of ticket management tools used in the cyber domain industry to implement UCO.
Competencies demonstrated
Competency 1
Competency Question 1.1
Result 1.1
Competency Question 1.2
Result 1.2
Solution suggestion
Coordination
developfor the next releasedevelopstate with backwards-compatible implementation merged intodevelop-2.0.0develop-2.0.0(or N/A)The text was updated successfully, but these errors were encountered: