subclass vs property

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

subclass vs property

Laura Morales
If I want to model a customer support ticketing system, there are several type or "requests" that can be received, for example "commercial" "info" "bug report" "login issue" "merch. order" and so forth. How do I get to decide if it's better to use a property "isType: commercial/bug/order/..." or subclasses of a general "Request" class? For instance

Request
  |_ CommercialRequest
  |_ BugReportRequest
  |_ MerchRequest
  |_ ...
_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: subclass vs property

Luis Enrique Ramos García
Hi Laura, 

in my opinion, much of this decision depends upon the whole design of the system,  and what kind of information do you have to determine that a request is a commercial request or a bug report request. 

You could work with swrl to "flag" individuals, and mark them as kind of request "isType: commercial/bug/order/...", but the question is if that is enough for your application?, the other possibility is that you have enough information to describe classes of requests, including some properties, and then you define them in order to use a reasoner later.

In all this you have to take in account that we are talking about description logic, and that logic have expressive constrains. 


Best regards


Luis Ramos

El sáb., 30 nov. 2019 a las 8:18, Laura Morales (<[hidden email]>) escribió:
If I want to model a customer support ticketing system, there are several type or "requests" that can be received, for example "commercial" "info" "bug report" "login issue" "merch. order" and so forth. How do I get to decide if it's better to use a property "isType: commercial/bug/order/..." or subclasses of a general "Request" class? For instance

Request
  |_ CommercialRequest
  |_ BugReportRequest
  |_ MerchRequest
  |_ ...
_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: subclass vs property

Igor Toujilov-2
In reply to this post by Laura Morales
There is no doubt the class hierarchy will help you tremendously. Consider a simple example: bug_report and its subclass reproducible_bug_report. If you have an instance of reproducible_bug_report, you only create an individual of reproducible_bug_report. If you use property isType, you will have to create at least two property assertions for this individual.


> Sent: Saturday, November 30, 2019 at 7:17 AM
> From: "Laura Morales" <[hidden email]>
> To: [hidden email], [hidden email]
> Subject: [protege-user] subclass vs property
>
> If I want to model a customer support ticketing system, there are several type or "requests" that can be received, for example "commercial" "info" "bug report" "login issue" "merch. order" and so forth. How do I get to decide if it's better to use a property "isType: commercial/bug/order/..." or subclasses of a general "Request" class? For instance
>
> Request
>   |_ CommercialRequest
>   |_ BugReportRequest
>   |_ MerchRequest
>   |_ ...
> _______________________________________________
> protege-user mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-user
>
_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: subclass vs property

Michael DeBellis-2
In reply to this post by Laura Morales
A few thoughts: 1) It's not necessarily either/or you could use both properties and classes. 

2) Classes are meant to model things that your system reasons about. Properties are meant to model relations between those things (object properties) and specific data such as name and age of a Person or dateCreated for a trouble ticket (data properties). In some object-oriented methodologies they say think of the nouns in your system (Account, Customer, TroubleTicket) as your classes and verbs and adjectives (things that describe relations between or specific data about nouns) are properties (e.g., ticketAccount for the Account that a specific TroubleTicket is for, accountCustomer for the customer associated with a specific account). Note though, it doesn't mean that classes are only for physical things,  it's often useful to have processes be modeled as classes as well. 

3) In your specific case you should consider if the various kinds of requests or trouble tickets have significantly different structure. So if you just have say a few fields such as problem (a textual description of the problem), priority, user, etc. that are the same for all requests than you may just want to have one class. If on the other hand there are significant differences in the kinds of properties that different kinds of tickets will have (e.g., a sales problem ticket may be very different from a technical problem) then you probably want to model the tickets as different classes. 

4) One thing that can be very powerful in OWL but takes some getting used to is that properties themselves can be in a hierarchy.  The Manchester FHKB tutorial is an excellent way to get familiar with this. 

On Fri, Nov 29, 2019 at 11:18 PM Laura Morales <[hidden email]> wrote:
If I want to model a customer support ticketing system, there are several type or "requests" that can be received, for example "commercial" "info" "bug report" "login issue" "merch. order" and so forth. How do I get to decide if it's better to use a property "isType: commercial/bug/order/..." or subclasses of a general "Request" class? For instance

Request
  |_ CommercialRequest
  |_ BugReportRequest
  |_ MerchRequest
  |_ ...
_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user