- From: Dave Reynolds <dave.e.reynolds@gmail.com>
- Date: Wed, 17 Apr 2013 13:48:42 +0100
- To: public-gld-comments@w3.org
Exactly. ORG provides a foundation but leaves some freedom in how you represent the types of organization of interest. You can create sub-classes of org:Organization or you can create classification schemes (represented as skos:ConceptSchemes) and use org:classification. Which you do depends on your use case. This is a general modelling problem and there's lots of advice out there. My personal rule of thumb is that if the type of the organization is intrinsic to its nature and affects what properties you would use to describe it, then use a class. If it's just a way of arranging things in convenient groups then use a classification property. It is also possible to mix and match the two approaches. For example, have a class hierarchy to distinguish public bodies, charities and commercial organizations. Perhaps also differentiate the types of commercial entity recognized in your legal jurisdiction (sole trader, limited company, public limited company whatever). But to differentiate a manufacturing company from a financial services company, or a washer manufacturer from a fridge manufacturer, then use a classification scheme. Not knowing anything about your use case my inclination would be to have small subclass hierarchy: org:Organzation my:publicBody my:RegionalAdministrativeBody Dave On Wed, Apr 17, 2013 at 1:40 PM, Dave Reynolds <dave.e.reynolds@gmail.com> wrote: > Exactly. > > ORG provides a foundation but leaves some freedom in how you represent the > types of organization of interest. You can create sub-classes of > org:Organization or you can create classification schemes (represented as > skos:ConceptSchemes) and use org:classification. > > Which you do depends on your use case. This is a general modelling problem > and there's lots of advice out there. My personal rule of thumb is that if > the type of the organization is intrinsic to its nature and affects what > properties you would use to describe it, then use a class. If it's just a > way of arranging things in convenient groups then use a classification > property. > > It is also possible to mix and match the two approaches. For example, have a > class hierarchy to distinguish public bodies, charities and commercial > organizations. Perhaps also differentiate the types of commercial entity > recognized in your legal jurisdiction (sole trader, limited company, public > limited company etc). But to differentiate a manufacturing company from a > financial services company, or a washer manufacturer from a fridge > manufacturer, then use a classification scheme. > > Not knowing anything about your use case my inclination would be to have > small subclass hierarchy: > org:Organzation > my:publicBody > my:RegionalAdministrativeBody > > Dave > > > > On 17/04/13 13:17, Christopher Gutteridge wrote: >> >> It sounds to me a little buggy. The rov: namespace is about "registered >> organizations" but switches to assume these are companies, which they >> may not be... eg. charities etc. >> >> That said, rov:companyType is a sub-propety of org:classification, so >> why not use that term instead which is acceptable for any organization, >> company or otherwise? >> >> On 17/04/13 09:32, Chris Beer wrote: >>> >>> Hi Kotis >>> >>> Saw this -> randomly jumping in. >>> >>> My first instinct (noting the similarities in our organisations in >>> terms of names ;) ) would be to see your example as an ORG unit/entity >>> which has the function of Regional Administration. >>> >>> If the RAB's in Greece conduct a commercial activity (as opposed to >>> say simply setting policy priorities and administrating grant funding >>> as a public sector function) then certainly here they would fit the >>> description of a rov:companyType ( we call them a Government Business >>> Enterprise or GBE - and we would link back to ORG to a Department of >>> State and associated Cabinet Minister through a PROV change event >>> such as our Financial Management Act which governs how the public >>> sector can engage with the public commercially). >>> >>> I guess what I am suggesting is to look to already defined PROV and >>> ORG entities etc, to see if a logical combination presents itself >>> which would alleviate the creation of a bespoke concept? >>> >>> 2 cents worth - feel free to disregard or vehemently argue all. :) >>> >>> Cheers >>> >>> Chris >>> >>> ----------------------- >>> >>> Chris Beer >>> Manager - Online Services >>> Department of Regional Australia, Local Government, Arts and Sport >>> >>> All views my own unless otherwise stated >>> >>> >>> Sent from my ASUS Eee Pad >>> >>> Kotis Kostas <kotis@aegean.gr> wrote: >>> >>>> Dear Phil, >>>> >>>> I am working on an ontology for 'IT helpdesk support ticketing' for >>>> public sector organizations (eGov) and I am using ORG and RegOrg >>>> vocabularies for some upper level descriptions of example data. I >>>> think that rov:companyType property is not suitable for public >>>> organizations, or is it? Introducing for instance a concept "Regional >>>> Administration Body' in order to classify an instance such as the >>>> public organization 'North Aegean Regional Administration' body of >>>> Greece, could be possbile? >>>> >>>> Thanks in advance, >>>> >>>> Konstantinos Kotis, PhD >>>> Post Doctoral Research Scientist >>>> Department of Digital Systems, University of Piraeus. >>>> Head of IT Department >>>> Samos Regional Unit, North Aegean Region Admin. Authority. >>>> >>>> Greece >>>> +30 6974822712 >>>> http://gr.linkedin.com/in/kotis >> >> >
Received on Wednesday, 17 April 2013 12:49:09 UTC