A profile can have multiple base specifications [ID37] (5.37)

[nicholascar]

Entered from Google Doc

[aisaac]

This requirement as been approved but it needed to be rewritten from "A vocabulary or data model can be a profile of several other vocabularies or data models at once" to something else. There were four suggestions:

• A profile can be based on several data models or vocabularies at the same time
• A profile can be dependent several vocabularies or data models at the same time
• A profile can be dependent on several vocabularies or data models at the same time
• A profile can have multiple base specifications

I've chosen the last one for now, as it's the shorter and maybe the least contentious (it has a lower semantic commitment)

[agbeltran]

Further to discussions in the ProfGui sprint and some iterations in the Google doc, I propose the following text:

A profile MAY be based on multiple specifications, which are referred as base specifications in this document, which is the role the specifications assume by providing the foundation for the profile. A profile can have multiple base specifications. A profile can use all or part of the elements from a base specification.

For example, a profile MAY be based on several data models and vocabularies at the same time. In profiles using XML schema or RDF technology, using multiple base specifications generally means using elements from multiple namespaces.

[agbeltran]

Further minor changes:

A profile MAY be based on multiple specifications, which are referred to as base specifications in this document, which is the role the specifications assume by providing the foundation for the profile. A profile can constrain all or some of the elements from a base specification.

For example, a profile MAY be based on several data models and vocabularies at the same time. In profiles using XML schema or RDF technology, using multiple base specifications generally means using elements from multiple namespaces.

[kcoyle]

Here's my understanding:

A profile is based on at least one pre-existing specification of vocabulary terms, with or without additional constraints. A profile may be based on any number of such pre-existing specifications. These are referred to in this document as 'base specifications.'

For example, a profile MAY be based on several data models and vocabularies at the same time. In profiles using XML schema or RDF technology, using multiple base specifications generally means using elements from multiple namespaces.

If we use "specfication" without saying more about the kind of specification, then one could conclude that a profile could be based on the banking rules of the IMO, which have no relation to metadata. This is my problem with using the term specification, because it is broader than what we are actually working with. I know that people hate the term "metadata" and there is push-back about refering to vocabularies, but if we do not have vocabulary terms (or whatever you wish to call them) then there are no profiles, no schemas and no namespaces. Our use of "specification" has to conceptually include those elements, and we should not refer to specifications that do not have them.

[agbeltran]

I see your point and I would resolve it by including the definition of 'specification' in section 1.1. and I had added a placeholder in the google doc. In addition, we could refer to 'metadata specifications' to make it clearer.

[aisaac]

+1 with @agbeltran , even though I may disagree with putting an additional definition, I think we shouldn't discuss the definitions in this requirement. It is only about saying that there can be several base specifications, not saying what a specification or (luckily for us here!) what this relation denotes.

All of @kcoyle 's comments apply to our official definition, so if there should be comments, they should be in relation to the official definition, not on this poor side requirement here :-)

If @agbeltran 's suggestion above feels too much like a general (and debatable) definition, then I suggest removing the part ", which are referred to as base specifications in this document, which is the role the specifications assume by providing the foundation for the profile. A profile can constrain all or some of the elements from a base specification." from it.

[aisaac]

By the way I have made a diagram to illustrate this requirement:

An example of profile with multiple base specifications (only two of them shown here): the Europeana Data Model, presented at https://w3c.github.io/dxwg/ucr/#ID37

[kcoyle]

We have the term "specifications" in italics so I assume that the intention is to define it. Given that the expression "base specifications" is used in various places, I think we should define it instead of just "specifications".

My question is whether we will require that profiles include vocabulary terms. (If not, I'm not sure what the profile could consist of.) If so, we should say that any "base specifications" have to have vocabulary terms that the profile makes use of. That then gives us a hook for "base specifications" which we can describe as documents or files that, among other things, include metadata vocabulary terms that the profile can reuse.

[kcoyle]

My re-write mainly is based on creating shorter sentences, because long ones with lots of clauses don't work well in English. Also, we should say that there is at least one base specification, not just that there can be more than one. This requirement is about "more than one" but I don't think we have a requirement that says "at least one" so it could fit here.

[aisaac]

@kcoyle. Point taken about the italics (or bold). My suggestion was precisely that if there's a (part of) sentence that suggests we're defining things in detail (and for the first time) here, then it should be moved elsewhere. So I'm going to be more explicit about my it. Here it is:

A profile MAY be based on multiple specifications. For example, a profile MAY be based on several data models and vocabularies at the same time. In profiles using XML schema or RDF technology, using multiple base specifications generally means using elements from multiple namespaces.

If there needs to be discussion about the def of base specification and inclusion of vocabulary terms, then it needs to happen in a wider scoped issue. Again we've got #507 and others for this. Unless you want to use this issue as a hook for the general discussion and include whatever was discussed in #507 and others? In this case then we need to consider that the use case may not be so general. It was the Europeana one. It could be ok, but when I wrote this requirement I certainly did not think the idea was to define what profiling is.

[rob-metalinkage]

This issue is superceded by #755 w.r.t. updates in descriptions There is no dispute about this requirement and it is explicitly handled in Profiles ontology examples.

[kcoyle]

@rob-metalinkage please ask others if they are ready to close. Do not take unilateral actions. The "due to close" label helps this.

[aisaac]

I'm also lukewarm on closing our big 'UCR' issues until we go through a more formal step of verifying that requirements are met.
In other words, it would make sense to close 'plenary-approved' issues in a plenary call. A "due to plenary close" could help here.
(and for the record I agree that indeed in this case the requirement has been met)

[rob-metalinkage]

Plenary is the wrong place - we should be following DCAT and normal procedure here and dealing with this in a specific sub-group. We havent succeeded in getting a regular profiles ontology sub group up - but if we replace the guidance slot with a profiles ontology we could go through the process and do checks. So lets convene a sprint on re-opening and try to resolve all the requirements issues in one shot.

[aisaac]

Is the DCAT group closing their requirements when they are met? If yes, then maybe I can live with such process, but I would certainly ask for a more general report from them in a plenary setting some day, so that everyone can validate their assessment!