What is core?

I have a few comments here that should perhaps be their own issues.

1. It's useful to know the geographic area to which an organization is associated. For example, to answer a fundamental democratic question "which elected officials represent this person?", the city council, provincial legislature and national parliament need to be associated to geographic areas. Same for the question "to whom should I report this pothole?" and many others.
2. It's useful to know an organization's founding date and dissolution date. For example, if an organization is dissolved, then you know that all the memberships and posts related to it are defunct. Schema.org has the properties "foundingDate" and "dissolutionDate".
3. If an organization changes name, it's useful to know the start and/or end dates of that usage. For example, if you are researching an organization's activities in the 1950s, it'd be useful to know its name at the time; since not all the documents you are searching through have been carefully timestamped, its historical name may be the only marker to aid your search. Another example: If you have an application that allows users to browse an organization and related facts over time (e.g. its last century's budgets), it's less confusing to the user to display the appropriate historical name and not the most recent prefLabel and a list of altLabels.
4. Another common use case is to contact an organization. vCard may be an appropriate standard to use here.
5. Many large public organizations have logos, which may be more recognizable to users than a name. Schema.org has an "image" property.
6. I can imagine some short or long description of an organization may be desirable, e.g. dcterms:abstract and/or dcterms:description.

I agree with James here. But we have to bear some things in mind :

• a semantic core is what defines on organization - probably most used are start- and end-date, but also official name. For me, these are obligatory things. Legal framework ought to be one of those, according to me.
• other information (logos, contact info, ...) is very usefull, but not necessary in order to define the org. Shouldn't be obliged in the voc.

Change events on core- or other aspects are something else entirely. Deponding on the case, you want the name change to be remembered or not (sometimes names are altered shortly after an organization is founded - policy makers then don't want the original to exist any longer...). A real change of organization (as a result of a fusion or task broadening) does need to be recorded in a new life phase.

Contact on the other hand (through vCard) seems not really adept to change events (or it would be out of judiciary reasons...).

Let me work through James's comments in order:

1. Re geographic coverage. We already have cpsv:administrativeLevel that links to a NUTS code. Do we also need to add in a more flexible property (presumably dcterms:spatial -> dcterms:Location) to cover geographic areas not defined by NUTS?

2. Founding data - that's a change event so I think that's already covered at least partially. Taking on board Thomas's comment, we can link the change event to a FormalFramework (defined in CPSV) which covers legislation and policies. So we have the legislation/policy that prompted the change event from which the organisation resulted. 

3. Name changes, again, that's covered by change events (and may be the result of a formal framework)

4. Contact? We have sites and site addresses and there's the open issue of whether we used VCard or LOCN for that. The original ORG ontology used VCard for the address. It was only the INSPIRE issue that, more or less at the last minute, led to VCard being dropped and it being left as rdf:Resource (i.e. anything).

5 & 6. It's easy enough to add in schema:logo (a refinemenet of schema:image) for the logo and dcterms:description - it depends on the WG's reaction to Thomas's point.

1. Is now covered in the NUTS issue: https://joinup.ec.europa.eu/asset/cpov/issue/use-cpsvadministrativeleve…

2. I suppose the term "change event" is confusing here, because a thing that doesn't exist cannot be changed into a thing that exists. Things that don't exist don't change (or do anything at all, really). The superclass of org:ChangeEvent is prov:Activity, which doesn't have this terminological issue.

3. Ok, I've added a link to your comment from the ChangeEvent issue.

4. Yes, but this is contact information for the organization, not one of its sites. One might argue that there is always a site at which the organization is contacted, but the phone number/email address may be routed to any number of sites (e.g. if it's for general intake), so it's doesn't make sense to attach contact information only to sites and not to organizations themselves. The site may also be unknown or mobile (e.g. a person with a mobile phone). In the use cases I've encountered, users don't care about the specific site at which the person answering to those contact methods is based; they just need to contact the organization.

4. yes an organization could have several org:hasSite (as org:Site) and several dcat:contactPoint (vcard:Address) !

I think that sites are important. Usually there is at least one site where a public organization is seated. For example Czech freedom of information legislation obliges public organizations to publish information about places where citizens and other subjects can for example file requests addressed to the public sector body. Location still matters for many agendas.

Xavier: dcat:contactPoint has a domain of dcat:Dataset, not an organization.

Jan: I'm happy to have both contacts and sites. I just don't think all contacts should require a site.

I  agree with  this  statement : "It could have  several org:hasSite (as org:Site) and  several dcat:contactPoint (vcard:Address)" 

Hi, Phil.

4. Contact? We have sites and site addresses and there's the open issue of whether we used VCard or LOCN for that. The original ORG ontology used VCard for the address. It was only the INSPIRE issue that, more or less at the last minute, led to VCard being dropped and it being left as rdf:Resource (i.e. anything).

I think this is still a good solution, since it gives organisations the ability to specify addresses in an INSPIRE-compliant way (by using LOCN), which in a EU context is important, leaving nonetheless the liberty of using another approach.

Said that, LOCN and vCard are not mutually exclusive. I can contribute a draft proposal on how they can be mapped. This would enable mutual conversion of addresses, irrespective of the vocabulary used.

5 & 6. It's easy enough to add in schema:logo (a refinemenet of schema:image) for the logo and dcterms:description - it depends on the WG's reaction to Thomas's point.

Another option is to use foaf:logo.

-Andrea

The issue of 'what is core' was addressed in the meeting on 2016-02-15. It was resolved that describing a public organisation, it was important to be able to say that one organisation was a member of another, but not describe the individuals or the roles they perform within in. Recorded in the minutes at https://joinup.ec.europa.eu/asset/cpov/document/cpov-wg-virtual-meeting…

Thanks Andrea,

I think a mapping between VCard and LOCN would be very useful (I think we did one originally, no?) Given the comments above it seems we'll need to have links to contact information that do not relate to specific sites so we'll be stepping outside ORG for that I think.