EventType subClassOf skos:Concept?

[clange]

What is the use case for this?

aeon/aeon.ttl

Line 1467 in 77a0ce7

rdfs:subClassOf <http://www.w3.org/2004/02/skos/core#Concept> ;

It looks strange to me, but without knowing the intended use case I can't tell whether it's good or bad.

[StroemPhi]

@clange: The idea behind making the EventType a skos:Concept is rooted in the fact, that there are no clear discriminators with which we can make a distinction that will hold in a global context as the definitions for the various event types vary depending on the sociocultural context.

[clange]

@StroemPhi looking at this once more, I think what you meant is aeon:EventType rdf:type skos:Concept, i.e., instance instead of subclass.

[StroemPhi]

@clange the instances of aeon:EventType are Conference, Workshop, etc. and yes they are suppose to be instances of skos:Concept so for example aeon:Conference rdf:type skos:Concept.
But how can I then group them in AEON if I can't make aeon:EventType a subclass of skos:Concept?
Or does that mean that we'd just have many individuals for skos:Concept and the range of aeon:has_event_type would be skos:Concept?

[StroemPhi]

@clange the same pattern holds true for AEON_0000027 ('academic field') & AEON_0000028 ('topic'). If this can be modeled better wrt the fact that they we need some way to bundle these named individuals of skos:Concept that are event types, academic fields or topics, I'm happy to change this.

[StroemPhi]

According to the SKOS specs, I should have probably been using skos:Collection alongside with the skos:member relation instead of skos:Concept in order to be able to group the skos:Concepts of academic field, event type and topic.

But as the SKOS logic combined with the OBO logic gives me a headache, I decide to subsume these thre classes under the iao:ICE branch sooner than intended.

Will be fixed in: https://github.com/tibonto/aeon/tree/issue51_fix_SKOS

[StroemPhi]

The two commits 578cb84 & a3f4a29 must be ignored, as they where made on a previous version of this issue branch, which I had to discard, due to me messing up with rebasing onto the main branch.

[StroemPhi]

So the idea is that event type becomes an iao:plan specification, as the type of an academic event is made up by the sociocultural format the organizers chose. The good thing about it being a plan spec is that this entails action and objective specifications. When we now also add to have condition specifications as part of the academic event type specification, we have everything needed to describe the plans of the organizers.
Providing named individuals for default academic event type specs of the defined academic event subclasses helps to classify real event data according to the way in which they are labeld in external databases or via their name. Once there is a large enough data set with objective, action and condition soecifications, we might be able to generalize those wrt to a particular event type spec. E.g. the data would allow to define an academic conference to be an event that has the objectives to have somewhere between 50 to 200 participants, produce proceedings of the submitted talks, which entails the conditions and actions specs of having a registration site, a admission fee etc.