Clarify chapter on dataset members in a dataset series

[matthiaspalmer]

We think that the current form of chapter 7.8 is problematic, for instance:

1. It gives the impression that it introduces a new class as it states it is a subclass of dcat:Dataset, this is not the case
2. It should not express frequency (dcterms:accrualPeriodicity)
3. Quite a few suitable properties are missing, e.g. dcterms:spatial and dcterms:temporal

We suggest rewriting this chapter and talk about which properties from dcat:Dataset that are expected and which are discouraged.

[init-dcat-ap-de]

https://github.com/SEMICeu/DCAT-AP/issues/155#issuecomment-1645660164

[bertvannuffelen]

@matthiaspalmer and @init-dcat-ap-de

I am puzzled how I should resolve this issue. As I mentioned in #155 there is implicitly an subclass. Namely the "Datasets that are member of a Dataset Series". The reason to make it explicit is to being able to express the rules in a condensed way.

For a "Dataset member of a Dataset Series" the relationship dcat:inSeries should exists (*). For a normal dataset this relationship cannot be present. We can thus categorize all datasets in 2 groups: those that have a relationship and those that do not have a relationship.

With the section 7.8 we add the requirements on datasets that have that relationship.

Now we have 2 modelling approaches:

1. we create an explicit subclass and force that use.
2. we do not create an subclass and rely on the implicit subclassing.

The reason for the choice of 2 in the modeling of 3.0.0 has the following motivations:

• avoids the need of explicitly changing class denotation from dcat:Dataset to _:DatasetMemberOfDatasetSeries, because of connecting the dataset with a DatasetSeries
• avoids the reclassification if a Dataset is removed from the DatasetSeries.
• allows to highlight the specific usage notes applicable for this case without the need to make for each impacted property of a Dataset a double sentence. (e.g. see the usage note in https://www.w3.org/TR/vocab-dcat-3/#Property:resource_previous, which scopes the use of previous to solely the datasets that are _:DatasetMemberOfDatasetSeries. I do not find this very user friendly.
• the need to have an correct representation in UML.

Observe that in DCAT-AP 3, the subclass relationships are meaningful in order to know which rules to follow: Dataset, DatasetSeries and DataService are subclass of dcat:Resource:

• they are share the same optional properties, but are distinct in each of the use of them. Catalogue is an independent entity
• it is distinct from the general rules imposed in DCAT-AP on all catalogued Resources (indicated by dcat:Resource ) DatasetMemberOfDatasetSeries is a subclass of Dataset
  • it shares all properties and constraints with Dataset
  • It adds additional requirements

One alternative could be to create a subprofile of DCAT-AP in which the datasets are only members of DatasetSeries. But if not needed I would not introduce it.

(*) I see now that dcat:inSeries is not yet mandatory. I think at least this direction should be mandatory.

[matthiaspalmer]

TLDR summary: I suggest to call it "entity profile" or "class profile" instead of "implicit subclass". Note that such a naming might have spillover effect on the rest of the specification, i.e. should "main entities" and "supportive entities" be renamed to "main entity profiles" and "supportive entity profiles" or "main class profiles" and "supportive class profiles"? Maybe such a change is good, it might further clarify that it is an application profile specification.

@bertvannuffelen my main concern is the wording "implicit subclass". When I read this I think of a situation where there is a real class :DatasetMemberOfDatasetSeries defined in RDFS / OWL and the dcat:inSeries are defined to have this as domain. Hence, having an instance of dcat:Dataset with the property dcat:inSeries would make it possible to infer that the instance is in fact an instance of the more specific class :DatasetMemberOfDatasetSeries. As defined in RDFS entailment rdfs2.

But you cannot just change the domain of dcat:inSeries in this way for two reasons:

1. You are not supposed to change the definitions of another organizations terms (best practise).
2. In an open world, you affect the entailment of all instances using dcat:inSeries, even those not signing up to using DCAT-AP3.

In principle we have to agree what is allowed to do in a profile. My perspective is that the following is allowed:

1. Introduce a new subclass.
2. Introduce a new property
3. The new property may have the new subclass as domain or range using RDFS
4. Existing propertis may be restricted to the new subclass, but not by using RDFS

So, how can we then restrict to the new subclass if we are not allowed to use rdfs:domain or rdfs:range. I would say in two ways:

1. By talking about restrictions in the textual documentation, i.e. in the table like constructions.
2. In shacl shapes.

But, from your answer above it seems like you are not in favour of actually creating a new subclass, instead you want the instances to still being typed only as dcat:Dataset. (And I agree, I think this is the right decision.)

Clearly, there is no problem in having two shacl shapes for dcat:Dataset. But you also have to be able to talk about that in the specification. Talking about another range is ok in existing tables in the specification, but we need a new table to talk about another "domain". I argue (above) that "implicit subclass" brings along the wrong connotations. I would instead propose to use the wording "class profile" or "entity profile".

Up to now we have not really seen situations where we need to have two "class profiles" for the same class within the same application profile, hence it have been enough to leave it vague.

[bertvannuffelen]

I agree that this topic is challenging and requires a proper solution.

This scoping is a general DCAT issue. Including blindly the subclass relationships may cause reasoning problems.

Maybe there is an alternative solution that pops into my mind: Namely that we would introduce the new class _:DatasetMemberOfDatasetSeries formally but require in DCAT-AP that this class is also annotated as its superclass dcat:Dataset. That thus this superclass relationship should not be inferred by a receiving party.

This approach might be closer to our objectives.

I would instead propose to use the wording "class profile" or "entity profile".

Up to now we have not really seen situations where we need to have two "class profiles" for the same class within the same application profile, hence it have been enough to leave it vague.

I like this term. It indeed covers the objectives.

As alternative to the above we could add the following Usage Note:

"This class is an entity profile for a DCAT-AP Dataset. This profile is applicable for all Datasets that are related with a DatasetSeries".

[jakubklimek]

I vote for explicitly introducing the subclass, avoiding the new modelling construct ("implicit class", which is human readable in documentation, but not visible to machines).

While I understand the requirement:

but require in DCAT-AP that this class is also annotated as its superclass dcat:Dataset.

it seems a bit strange to me to have it in the specification as an actual requirement, given that it is a redundancy. For ease of use, in my catalog implementation, I would include the dcat:Dataset class explicitly, but I would not like to be forced to do so, especially in a trivial case like this, where anyone can easily do a simple inference or simple SPARQL query to add the triples, if necessary or convenient.

Would we then also require this from instances of dcat:DatasetSeries, given that we fix the alignment with DCAT3 so that it is also explicitly a subclass of dcat:Dataset? Again, in the Czech catalog we do so, but should it be required?

[matthiaspalmer]

I vote against introducing the subclass, precisely because it will interfere with existing software searching for dcat:Dataset or encouraging / forcing this kind of double typing. Also, we have managed to work with the dcat:Dataset class for a long time without introducing subclasses, including the recent case with HVD Datasets. If W3C did not introduce a new class for this case, I think we should avoid it in DCAT-AP as well.

I think a clear usage note as suggested by @bertvannuffelen is the way to go. I would formulate it a little bit differently though to avoid claiming that it is a class:

The entity profile uses the class dcat:Dataset in combination with the mandatory property dcat:inSeries to points to the Dataset Series it belongs.

I also noticed that a definition is missing, I suggest a small adaption of the dataset definition:

A conceptual entity that represents part of the information published in a Dataset Series.

Closely related is how the term "entity" is used on it's own e.g. in the name of chapter 7 and 8. I think it is misleading as the word "entity" can be interpreted as both the instance / individual level as well as the class / pattern / shape level. Hence I would suggest to change the wording everywhere to reflect that we are talking about entity profiles whenever when we are doing so. I.e. chapter 7 would be named "Main entity profiles". By doing this it would be easier in chapter 7.8 to understand why we are talking about an entity profile, not a class.

This could also be a good reason for providing a usage notes for other subsections of chapter 7 and 8 where it is not stated clearly which class each entity profile corresponds to (only implicitly by the subsection being links to the correct class). E.g. the subsection 7.7 Dataset could have a usage note that simply says:

The Dataset entity profile is expressed by the class dcat:Dataset.

I believe such a change would make it clearer to everyone that we are not redefining existing classes, we are simply providing entity profiles for them. It should perhaps also be stated that each entity profile can be expressed formally by a SHACL shape, maybe the link of the subsection should even go to a stable identifier for such a shape, rather than to the class.

[bertvannuffelen]

If W3C did not introduce a new class for this case, I think we should avoid it in DCAT-AP as well.

I am reluctant to use that as motivation. In W3C DCAT everything is optional and each notion has the broadest interpretation possible. Our discussion originates that DCAT-AP tries to provide clear, coherent and structured use of DCAT in various well-defined situations. So in contrast to W3C DCAT which is searching for the most universal denominator, we are faced here with denoting a specific case to which only some cases will apply.

The argument "implementers" will face great amount of difficulty is from a semantically point ignorable, but from a practical point very strong. To a certain degree is this practical consideration the reason why I proposed this modeling, because it results in an easier to read representation on the contraints that are applicable for datasets in dataset series. Lets find a method that mitigates between both.

[jakubklimek]

@matthiaspalmer I was not entirely clear.

Going back to your initial issue, my actual first preference would be not having a separate chapter among other chapters for classes, suggesting (and explicitly saying) it is a class, which is confusing, and therefore not introducing a new class. I do not see any significant modelling differences of regular datasets and datasets in series that would need anything more than a usage note chapter similar to Chapter 14 Usage guide on Datasets, Distributions and Data Services, e.g. in Chapter 18 Example of dataset series,.

But, should the datasets that are in a series be considered so significant that they deserve a separate chapter among entities such as Dataset and Catalog, which so far seems to be the status quo, and we want to be able to work with them as domains/ranges for dcat:prev, dcat:next explicitly as it is now, then I they in fact are an explicit subclass (it is why we talk about them separately), introduced in DCAT-AP, and it should be named and used as such also in RDFS, and shown in UML, and this distinction should be explicit also to machines (seen as a class). I do not think it is a good idea to have an obvious subclass described in the human readable documentation, but not present in the machine readable representation. It is possible to validate this via SHACL, but SHACL is a validation language, not a language for semantic definitions. I think it does not really help with machine readable semantics to say that we will create some sort of "soft class", present in HTML, not present in RDFS, but validated via SHACL.

However, I do not view this as a big issue for implementations - programmers are used to working with inheritance in OOP, so why should it be such a big problem with RDF data and RDFS?

[jakubklimek]

Actually (and this may be later extracted into a separate issue), isn't this situation also kind of similar to the situation with distributions? We in fact have 2 subclasses of distributions we do not really talk about: distributions representing files (which have format, media type, bytesize), and distributions representing access through data service (which have accessService).

I do not mean to add complexity here, but it seems to me that whatever resolution we will achieve should be then applied consistently in these cases, and the case with dataset in dataset series is not the only one.

[init-dcat-ap-de]

I am also against a new subclass. I think it is not necessary at all. And if it's not a subclass, I would advise against calling it a class or a subclass.

Idea

Dataset

• add "in series" to Dataset,
• add to the usage note: "Datasets with this property are members of a DatasetSeries. As such, they must follow the conventions described in chapter Dataset member of a Dataset Series."

Dataset member of a Dataset Series

Definition:

A dataset that is part of a DatasetSeries, which is indicated by the use of the inSeries property.

Usage Note:

Compared to a normal dataset, the following properties have more specific Usage Notes.... The prev and next properties should only be used in conjunction with inSeries, which is checked using SHACL.

[bertvannuffelen]

@init-dcat-ap-de your proposal is unfortunately not realisable.

For Datasets that are not in a series the minCard of dcat:inSeries is 0, while for Datasets that are in a series the minCard is 1. So what is the value of the cardinality for dcat:inSeries in dcat:Dataset [0,1 .. n] ?

"Conditional" (usage) constraints that depend on the values of other properties are very difficult to maintain and to explain. When adding these, the community will come back for a separate overview of what is required in each case. And then we are back to the start of the discussion.

We face here an entity-profile representation challenge: a) it in the same specification b) it is in distinct specifications

The current proposal applies a) with denoting the entity profile with a unique name but mapping it to the superclass. Maybe the way out is to apply b) in this case. In that case the scope of the new specification is "Datasets in the context of Dataset Series".

If we stick to proposal a) an agreement has to be found on how to express entity profiles. And maybe we have to continue discussing that, as @jakubklimek mentioned that the same case might happen for Distribution too.

[init-dcat-ap-de]

@bertvannuffelen a Dataset in a DatasetSeries is a Dataset. The cardinality for inSeries would be 0..n. IF there is any inSeries, the additional constraints apply (mainly: more specific usage notes which are not enforcable anyways and the addition of next/prev which make no sense outside of the series).

So I really don't see the big difference to what you are currently doing.

[jakubklimek]

If I understand it correctly, the intention is to somehow consistently and explicitly cover both cases, i.e. that for "Dataset in a DatasetSeries", with cardinality of dcat:inSeries 1..n & dcat:prev/dcat:next usage notes, and for datasets outside of the series, where the cardinality of dcat:inSeries is technically 0..n, but actually it does not make sense to use this property (and dcat:prev/dcat:next) at all. Moreover, the intention is to explicitly state the applicable usage notes for the inSeries case without introducing conditions in the more generic usage notes for Dataset itself. The more specific conditions are then enforcable by SHACL shapes targeting shacl:subjectsOf dcat:inSeries.

Let me see if I can get the discussed alternatives right:

Alternative a) mixes the expected Classes (Dataset, Catalog) with an unexpected "entity profile Dataset in a DatasetSeries" in the same chapter (and talking about it as a subclass), which seems confusing, as it is currently not the intention. This is the current state. I do not like it and @matthiaspalmer also seems not to like it based on the original issue.

Alternative b) where @bertvannuffelen suggests creating a entity profile for Dataset in a DatasetSeries, i.e. a profile within a profile, clearly scoping it to those. Relatively easy to do, can be validated using SHACL. This could be a separate chapter similarly to data services, rather than a completely separate document (that would be an overkill). Is a case of Reuse of a class with terminological adaptations. If we go this way, more cases like this may emerge, like Distributions, if we want to be consistent.

Alternative c) - where @init-dcat-ap-de suggests dealing with it using a note with a conditional "if this is a dataset in series, then ..." in the usage note of Dataset - which is what @bertvannuffelen tries to avoid. This too could be validated using the same SHACL shapes as above.

Alternative d) - making it a proper subclass within DCAT-AP, in line with Reuse of a class with semantic adaptations. In the strict modeling sense it is a subclass - we are obviously talking about it, so it exists, and subclass is nothing more than a subset - datasets in dataset series are clearly a subset of all datasets. This is semantically clean, clear how to do, would look the same as it currently does in the specification, but is viewed as too complex for implementors and for what we are trying to achieve by all but @jakubklimek . If we go this way, more cases like this may emerge, like Distributions, if we want to be consistent.

Did I miss anything? Any other suggestions?

[init-dcat-ap-de]

Thank you @jakubklimek for the comprehension. I fail to see the difference between b) and c), at least on the RDF-level for datasets. As you say: the SHACL shapes are the same... I have no strong feelings about the question where in the specification the information about Datasets in a DatasetSeries can be found. As long as we don't make them a sub-class and don't call them a sub-class. (Or if we call them a sub-class, we should explain, what we mean when we call them a sub-class.)

[jakubklimek]

Yes, on RDF level, b) and c) seem similar, maybe except for usage notes, where in c) there will be the conditions in the usage notes even for people who do not have dataset series. With b), I don't know - I am a bit afraid that this leads to multiple, machine undistinguishable usage notes on Dataset and the involved properties, e.g.:

dcat:Dataset vann:usageNote "Regular datasets..."@en , "When in dataset series..."@en.

which I do not like - makes it impossible to determine, which is which. To distinguish those, we would need a separate class, i.e. d).

But as far as I can see, there is currently no RDF version of DCAT-AP 3.0.0 and I don't know if the plan is to have it as with the previous releases.

[matthiaspalmer]

Thanks @jakubklimek for the summary, I fully agree with the options. Just to clarify, I have argued against a) and d) for reasons stated earlier.

[bertvannuffelen]

These are possible options.

I would like to explicitly add to this discussion that this is a representation challenge for building profiles. And that the outcome will impact the design of any derived specification.

This is about specialisation of a class present in an external vocabulary. The fact that this specialisation is not present is a natural case. Any broad, universal vocabulary will not provide names for any possible specialisation users can think of.

Argumenting that because the specialisation is not present in the external vocabulary, one therefore cannot introduce a new subclass in a profile prevents essentially the profiling. I like to point out this remark from @jakubklimek

• we are obviously talking about it, so it exists, and subclass is nothing more than a subset -

Nevertheless we experience the issue that creating subclasses may give the impression that one has to explicitly must instances of these with the explicit subclass annotation.

So to add to option d) we could formally state that all member of a subclass are the superclass that satisfy a graph (derived class). And add to the conformance statement that one shares these subclass instances as superclass instances. Of-course such an approach only works if there is a formal expression that would bind them together. If that does not exist then the subclass becomes explicit.

[matthiaspalmer]

That formal expression would in this case correspond to redefining an existing property like dcat:inSeries, don't you agree @bertvannuffelen? And redefining existing classes and properties is bad, we can agree on that right?

Also, I would like to remind everyone that DCAT-AP is clearly an "Application Profile", it is in the name.

The approach taken of defining application profile is different from the approach where you create OWL ontologies for new needs. I think it it fair to say that the main difference is that it avoids introducing new classes and properties as far as possible. One of the reasons for this is to achieve practical interoperability without having to rely in more complex inferences.

Clearly, a range or domain restrictions on some property can make a dataset to be an instance of a subclass implicitly. But this kind of informal agreement to only express the superclass will not be followed by everyone and you will have to rely on inference to achieve the interoperability in the end.

I argue we should to stick to the "AP" in DCAT-AP to maximize interoperability without requiring inference. This is what I consider being the main argument against introducing subclasses, implicitly or not.

[matthiaspalmer]

@jakubklimek regarding the machine readability of vann:usageNote, have you checked the OWL representation of DCAT-AP? It is clearly not thought through.

For instance let's check all usageNotes on dcterms:title:

<http://purl.org/dc/terms/title">
    <vann:usageNote xml:lang="en">Mandatory property. This property contains a name given to the Catalogue. This property can be repeated for parallel language versions of the name.</vann:usageNote>
    <vann:usageNote xml:lang="en">Mandatory property. This property contains a name given to the Data Service. This property can be repeated for parallel language versions of the name.</vann:usageNote>
    <vann:usageNote xml:lang="en">Mandatory property. This property contains a name given to the Dataset. This property can be repeated for parallel language versions of the name.</vann:usageNote>
...

The same problem is for the rdfs:label and rdfs:comment, just check in the OWL file for 2.2.1.

Clearly, the triples are conflicting and they only make sense for a human that looks at that particular file, if parsed and serialised they are not distinguishable anymore which one refer to which class.

The OWL expression from W3C does not do this, it only contains the new classes and properties introduced as part of DCAT. For reused classes and properties, e.g. DCTerms and SKOS, they are imported via owl:import (which is best practise). If you take the same approach for DCAT-AP the OWL file will be reduced to contain a single property (I think, have not checked everything), i.e. http://data.europa.eu/r5r/availability.

That makes me conclude that DCAT-AP OWL file is not really an OWL file at all, it is an attempt to express an Application Profile as OWL, which fails if you look at it seriously.

There have been multiple attempts at formally encoding application profiles in RDF, e.g. DCAP see RDF vocabulary and DSP (part of the Singapore framework, can't find the RDF expression right now). But right now I would say SHACL is sufficient for describing application profiles, perhaps with a few extra tweaks (e.g. to indicate the difference between the main and supportive entities).

Conclusion: we should provide documentation in the form of definitions and usageNotes on SHACL shapes not on classes and properties.

I think this look into the RDF expressions informs us that we either need to talk directly about SHACL, i.e. node shapes and property shapes in the DCAT-AP specification. Or, alternatively, if the terminology feels to technical we could use another terminology like the one I suggested earlier. E.g.

An application profile may contain:

1. new vocabulary in the form of new classes and properties
2. a set of entity profiles and connected property profiles

Where 2 is used to inform how classes and properties should be used (both existing and new) for someone to be compliant with the application profile.

[bertvannuffelen]

That formal expression would in this case correspond to redefining an existing property like dcat:inSeries, don't you agree @bertvannuffelen? And redefining existing classes and properties is bad, we can agree on that right?

The formal expression which I mentions is a formally strict way to express the human readible semantics. It acts like a constraints. It is not about redefining classes and properties. ( I do not know what you had in mind.)

I can state in formal English: "DatasetInDatasetSeries" = the Datasets for which all inSeries (dcat:inSeries) have at least one value. This is not redefining anything.

Then I can state that for any previous of a DatasetInDatasetSeries should also be in the same DatasetSeries.

Also, I would like to remind everyone that DCAT-AP is clearly an "Application Profile", it is in the name.

The approach taken of defining application profile is different from the approach where you create OWL ontologies for new needs. I think it it fair to say that the main difference is that it avoids introducing new classes and properties as far as possible. One of the reasons for this is to achieve practical interoperability without having to rely in more complex inferences.

That really depends on the scope, domain and existing vocabularies. I would not be so strict about it.

Clearly, a range or domain restrictions on some property can make a dataset to be an instance of a subclass implicitly. But this kind of informal agreement to only express the superclass will not be followed by everyone and you will have to rely on inference to achieve the interoperability in the end.

I argue we should to stick to the "AP" in DCAT-AP to maximize interoperability without requiring inference. This is what I consider being the main argument against introducing subclasses, implicitly or not.

In general I agree that we should minimize the need for inference. But this topic will in many aspects require to accept a form of inference. Subclassing is not the worst thing to do. It may be the most elegant, condensed and clean way to do. So I would not rule it out.

I think we should be open for updated conformance statements and inference. If we are very strict, then the values of all ranges referring to a Controlled Vocabulary must be explicitely typed as "skos:Concept". Also here we agreed a form of implicit inference. Similary, here, we could agree that the subclass DatasetInDatasetSeries is an empherical class to denote the entities of interest.

[bertvannuffelen]

But right now I would say SHACL is sufficient for describing application profiles, perhaps with a few extra tweaks (e.g. to indicate the difference between the main and supportive entities).

I disagree here: SHACL is just a mean and should not be used as the sole normative language for an application profile. Many of the usage notes (e.g. the whole section on legal information) is beyond what SHACL can offer. Any formal expression language has its limits. And in an application profile we always go beyond. That is the reason why we write a human specification.

In addition SHACL comes also with inference issues. As you we see in the SHACL validator for DCAT-AP, whether or not you include the background theory (dcat.owl, foaf, etc) will impact the validation outcome. Subclass inference is part of SHACL but many people are not aware of it. Which means we cannot just impose SHACL without defining how owl:imports should be handled.

I though agree that for the RDF/Semantic Web community SHACL should be the normative language to express as much as possible of the application profile constraints. But others could argue that it should be SHEX or OWL2.
We have to also understand that an application profile is being processed by people that do not know SHACL, but want to have a firm understanding of the application profile.

In an application profile we have to balance all this: the human insights and the capabilities of formal languages. It is a give and take. And it means we might have to express it sometimes in a way that is not ideal for one perspective/tool/representation.

[init-dcat-ap-de]

Let me play devils advocate: I think a subclass or even a special chapter for DatasetMemberOfDatasetSeries is absolute overkill. 1) We are talking about 3 updated usage notes and 3 properties which only make sense for Datasets in a DatasetSeries. 2) We are focusing a lot on sequential dataset series where the dataset is somewhat different than a "normal" dataset. But there are also DatasetMemberOfDatasetSeries which just happen to be put into a DatasetSeries. Their only difference is that they use dcat:inSeries (e.g. a series of curated datasets).

So why not adding the usage notes from https://semiceu.github.io/DCAT-AP/releases/3.0.0/#DatasetmemberofaDatasetSeries directly to https://semiceu.github.io/DCAT-AP/releases/3.0.0/#Dataset

property	usage note
dct:title	This property can be repeated for parallel language versions of the name. If the dataset is member of a dataset series, the title may indicate the dimension values.

In https://semiceu.github.io/DCAT-AP/releases/3.0.0/#DatasetSeries we have to put the information stored in the old range into the usage note as well

Property	Range	Definition	Usage
dcat:first	dcat:Dataset	The first resource in an ordered collection or series of resources, to which the current resource belongs.	The dataset should use dcat:inSeries to point to this DatasetSeries.

More details can be given in https://semiceu.github.io/DCAT-AP/releases/3.0.0/#usage-guide-on-dataset-series

[matthiaspalmer]

Just to clarify, what you just wrote above @init-dcat-ap-de is alternative c) according to what @jakubklimek wrote above.

I think c) is fine, but I would prefer alternative b) if it would be put to a vote.

[matthiaspalmer]

@bertvannuffelen I agree that the human specification is useful in conveying semantics through the English language, I am not disputing or suggesting to remove any of that.

I do think though that we in addition to the human specification should aim to capture as much as possible of the semantics of the application profile in a formal language. I think SHACL is much better than RDFS or OWL for this purpose.

[terjesyl]

Depending on which proposal we end up with, should the cardinality of inSeries for a Dataset member of Dataset Series be changed from 0.. to 1.. ?

[bertvannuffelen]

Thanks for the discussion and interactions. As you have seen in the past DCAT-AP webinars, the SEMIC blog post on modeling application profiles (https://joinup.ec.europa.eu/collection/semic-support-centre/application-profiles-what-are-they-and-how-model-and-reuse-them-properly-look-through-dcat-ap), and the upcomming webinar on this topic (see https://joinup.ec.europa.eu/collection/semic-support-centre/event/third-webinar-semic-style-guide) that your questions, feedback and interest drive us to improve the Semantic Community.

Despite that this topic has probably not got to a firm conclusion, we propose to close it. And take the discussions from the agreements and insights gathered throughout all these activities.