property profileOfTransitive

[riccardoAlbertoni]

I guess the intention for profileOfTransitive was to replicate the modelling pattern adopted for the broaderTransitive and broader properties in SKOS. In that case, I have two issues:

• I would consider renaming this property in "transitiveProfileOf". Of course, I leave the last word to native speakers but while "broaderTransitive" works well to me, "profileOfTransitive" is a little confusing, probably due to the 'Of" before "Transitive" which might be interpret as "profile of transitive" instead of "profileOf transitive".

• In order to replicate the skos:broader /skos:broaderTransitive, the following statement might be added

  
  prof:profileOfTransitive rdf:type owl:ObjectProperty , owl:TransitiveProperty .
  prof:profileOf rdfs:subPropertyOf prof:profileOfTransitive .

[kcoyle]

@riccardoAlbertoni I will give you a thumbs up from a native speaker point of view regarding profileOfTransitive, but I would also question whether "transitive" expresses the intended meaning here. Although the usage here is similar to SKOS's broaderTransitive, I feel like the relationships between profiles is more complex than the "broader/narrower" type as used in SKOS. I am thinking of the case where:

vocabularyA exists
vocabularyB exists
profileC is a profile of A and B although it uses only portions of A and B
profileD is a profile of C using some portions of profileC but adding terms from another vocabulary

Under what conditions could you say that profileD is a profile of(transitive) profileC? Do they have to use all of the same terms and constraints? I feel like this question gets very complex very quickly. At the very least, there would need to be rules that govern transitivity.

[rob-metalinkage]

Happy to take on board the suggestion and see what the consensus is.

its important to be clear of the semantics here :-)

def of transitive : "(of a relation) such that, if it applies between successive members of a sequence, it must also apply between any two members taken in order. For instance, if A is larger than B, and B is larger than C, then A is larger than C."

or in the OWL spec; "When one defines a property P to be a transitive property, this means that if a pair (x,y) is an instance of P, and the pair (y,z) is also instance of P, then we can infer the the pair (x,z) is also an instance of P."

a object conforming to profile A is also conformant to all profiles P where A transitiveProfileOf P

so for the case: "profileC is a profile of A and B although it uses only portions of A and B "

profileC is still bound by any cardinality constraints in either A or B

NB a vocabulary where terms are defined and no cardinality is defined (everything is optional) means that any object may "conform" to it if the use of those properties are consistent. We may need to think about the case where no properties are used at all

is the graph

"A1 a owl:Thing . "

conformant to a profile of dublin core that introduces no cardinality constraints?

would we need to safeguard reasoners against lots of trivial conformance statements?

[rob-metalinkage]

also we could consider

profileTransitiveOf

as perhaps closest to the skos without the ambiguity ?

[kcoyle]

@rob-metalinkage If "profileOf" and transitive here means "bound by cardinality constraints" then that needs to be included somewhere in the document. There is nothing inherent in "profile of" conceptually that would imply such a rule. The OWL definition of transitive establishes a relationship but does not define specific rules based on the entailments from that relationship, which presumably would depend on the nature of the things being related. Even if we could say that "bound by cardinality constraints" is a logical result of the "profileOf" relationship, I think that needs to be made clear for readers. I'm also wondering what other entailments might be assumed from the profileOf relationship - including things like labels, definitions, etc.

[rob-metalinkage]

agree we should make sure its well explained in examples.

profile transitivity is a simple declarative statement that is transitive.

The existence of resources that are qualified by the profile that introduced the resource could be expressed as an entailment of the resource property.

these are the only two I think.

Do you think any other entailments are appropriate and why?

[kcoyle]

Actually, I prefer not to assume entailments, because in general I think they are not used/implemented. I also think that they are often not understood. So if this vocabulary includes some functionality based on entailments that needs to be expressed very clearly.

I have not yet encountered a profile that has functionalized entailments from its base vocabularies. However, it may be that people haven't thought about it, so a good explanation (even as a note accompanying the proposed vocabulary) would be useful.

[nicholascar]

@kcoyle we do see profiles using entailment from base vocabs every time a Profile extends a structured codelists, e.g. a vocab. By placing new terms in a hierarchy - maybe addin more, finer grained leaf nodes, the profile is leveraging the base space vocab’s hierarchy for classification.

Also, any specialised ontology of another is a profile carrying forward entailments from the base spec.

Having said that, I agree with you this is rare for people in pure DCAP-like profile land and also agree it’s probably because people haven’t easily had the mechanics at hand to do this and that they may now be able to do it more - a functional win.

[kcoyle]

@nicholascar "Also, any specialised ontology of another is a profile carrying forward entailments from the base spec."

Here I think we need to carefully define what we mean by "entailment". The meaning I was using was the actual axiomatic usage in RDF, which is effected in code. This kind of entailment adds triples to the graph. In a non-RDF environment, it would add some code to existing code, as in your example of placing new terms in a hierarchy.

I do not use "entailment" to mean intellectual or semantic "carry-over", such as re-using dct:title without further definition because your community knows very well what it means.

I agree with @agreiner in her concerns about "cascading" profiles, and I think that the profiles that we see in the wild support her view that a stand-alone profile is what most people are comfortable with. For that reason, I think that any entailments inherent in the ontology need to be clearly spelled out - in part so that people can understand if they need them.

This is my worry about "profileOf" - one could say that DCAT-AP is a profileOf DCAT, yet DCAT-AP does not allow any code entailments from DCAT, AFAIK. If "profileOf" means that there are entailments, then it would not be correct for DCAT-AP to use that. Yet it seems quite natural to consider DCAT-AP a profile of DCAT. So the definition and implications of the use of "profileOf" are very important and need to be spelled out. Can a stand-alone profile be a profileOf something? What is the algorithm for entailment of profileOf? In ODRL it means (as I understand it) to carry forward ALL properties of the base profile. I don't think that's what we mean since we say that profiles can select properties from a variety of base vocabularies. So what exactly is the effect of profileOf on the content of the profile?

[aisaac]

I'm sorry to be a pain, but this issue has become quite unreadable. I guess the notion of the 'transitive profile of' property is just to be able to navigate over chains of 'profile of' statements, whatever the single 'profile of' steps may mean in terms of entailment, partial or full conformance, etc. If it's the case, then discussion on what the single 'profile of' steps mean, relevant at it is, should be transfered to another ticket.

[kcoyle]

I agree. I'll start a new issue and copy some of this over.

[aisaac]

Maybe the discussion on w3c/dxwg#507 will result in a change of name from 'profile of' to something else. But in any case, +1 for @riccardoAlbertoni 's original suggestions on the patterns, both the naming pattern and the axioms to be added.

[rob-metalinkage]

I'm happy to make these changes before FPWD. do we have consensus?

profileOfTransitive => transitiveProfileOf

prof:transitiveProfileOf rdf:type owl:ObjectProperty , owl:TransitiveProperty . prof:transitiveProfileOf rdfs:comment "This is consistent with the SKOS model of broader and broaderTransitive" . prof:profileOf rdfs:subPropertyOf prof:transitiveProfileOf .

+1 from me, @aisaac and @riccardoAlbertoni (presumed) so far then

[nicholascar]

+1 although the rdfs:comment might work better as a skos:usageNote reading: "This is consistent with the SKOS model of broader and broaderTransitive and should be used accordingly."

[agreiner]

Karen has asked some important questions about the transitivity concept that I've been hoping to see some answers to myself. I am having a hard time thinking of real-world use cases for this, and I think that needs to be balanced against the complexity. Does it even make sense to make claims about transitivity when defining only one profile? What would they mean? What would such statements enable?

[rob-metalinkage]

@agreiner please refer to the multiple Use Cases that clearly identify that profiles are transitively hierarchical (they inherit all constraints of base profiles). So we provide a way to "flatten" these things out so that clients do not need to walk the hierarchy if a server is willing to do the work to flatten them out.

or look at the SKOS spec, and the way skos:broaderTransitive is defined - and may be entailed from skos:broader (or provided entailed in the resource at the server's discretion)

fair enough to think about best practices for entailment (and avoiding run-time entailment) but the rationale is clear enough, and the requirements have been discussed multiple times and agreed, so now we need to focus on a solution, not re-opening the debate.

[kcoyle]

I think we should look closely at those "multiple use cases" to try to understand what definition of "hierarchy" they require. Which ones are you referring to?

[rob-metalinkage]

Europeana, DCAT-AP family, Nicks Aust gov example. We dont actually have any examples without a hierarchy.

[nicholascar]

Property profileOfTransitive renamed to transitiveProfileOf in commit https://github.com/w3c/dxwg/commit/be299e465b76d99a2a36c1df681840bbed15dbbd

[kcoyle]

Ok, both Europeana and DCAT-AP have made clear that their profiles are "flat" - that is, every profile is a stand-alone. There is logical semantic "inheritance" but no algorithmic inheritance is required or desired. That is one case for profiles, and it seems to be by far the predominant one. There is no "transitivitiy" to act on in these profiles. In fact, it would probably be inaccurate to say that every instance of DCAT-AP-x is a valid DCAT-AP, as some changes may have been made. For sure, other elements have been added that would not be valid in DCAT-AP. Therefore, they are not hierarchical, in the broader, narrower sense, and they are not transitive, as the changes would make them invalid.

[rob-metalinkage]

" There is logical semantic "inheritance" " - hence the abstract model has inheritance and this is supported by the profiles ontology

" that is, every profile is a stand-alone." - hence the profiles ontology supports implementations that are "flat"

The issue of non-conformance is more complicated - no formalism would ever allow this - so if this is the case they are not profiles of each other - only confusingly named. What we need then is additional evidence in the Use Case and additiona requirements - and we could respond with additional support in the profiles ontology ( notAProfileOF X) to indicate this semantic disjointedness.

[rob-metalinkage]

it does sound that it would be a requirement to have a specialisation of role to distinguish between artefacts that are flat and those that are normative constraints specific to profile

[kcoyle]

@rob-metalinkage Can you state what your definition of profile is, and what formalisms it requires? Because the definition we have now does not mention any requirement of inheritance or conformance that would be testable. As a shortcut, here's the definition:

A named set of constraints on one or more identified base specifications, including the identification of any implementing subclasses of datatypes, semantic interpretations, vocabularies, options and parameters of those base specifications necessary to accomplish a particular function.

Also, based on this definition, is DCAT-AP a profile? Does it meet your definition of profile?

[rob-metalinkage]

I think this is worth making more explicit - that a profile itself is a specification. Whilst its pretty obvious under any rational interpretation of specification that a set of constraints is a specification, I think you have raised a valid concern about its ease of interpretation, and it won't hurt to reinforce this:

A profile is a specification consisting of a named set of constraints on one or more identified base specifications, including the identification of any implementing subclasses of datatypes, semantic interpretations, vocabularies, options and parameters of those base specifications necessary to accomplish a particular function.

It does not specify testability as this is a platform and community specific concern - there is a default assumption of testability of "by inspection" that doesnt need to be in the definition.

DCAT-AP is a profile of DCAT if and only if data conformant to DCAT-AP is conformant to DCAT (which I understand is true)

If we have a requirement to express "partial conformance" we need an explicit use case we can derive it from.

[kcoyle]

@rob-metalinkage I don't know what adding the word "specification" does here. Can you say what difference it makes? Basically, what is the difference between "a profile is a named set of" vs "a profile is a specification consisting of a named set of"? Are you importing certain qualities to the word "specification" that are not already in the definition?

[smrgeoinfo]

Perhaps the idea is that a specification might include more than simply the constraints. The term constraints is a little tricky. Following the modular specification logic, its useful to think of a specification in terms of requirements and conformance classes. Most existing specs only explicitly define one conformance class--meets all requirements, and this typically is about some specific implementation/serialization/syntax. Usually there are some requirements stated using the standard RFC2119 language, but often there is an underlying implicit conceptual or logical model that establishes unstated requirements as well. Perhaps one of the problems with thinking about profiles is that they might conform to implicit requirements (conceptual or logical), but not the explicit one.

As far as transitivity, can we define different relations (names are for discussion purposes here). A and B are specifications; since multiple conformance classes are rarely defined, these are based on requirements. For example:

1. isType1ProfileOf -- if A isType1ProfileOf B, then instances of A meet ALL requirements in B, and requirements in A are all restrictions of requirements in B.
2. isType2ProfileOf -- if A isType2ProfileOf B, then instances of A meet a subset of requirements in B, and requirements in A are all restrictions of requirements in B.
3. isType3ProfileOf -- if A isType3ProfileOf B, then instances of A meet ALL requirements in B, and A adds additional requirements from other specifications that are not incompatible with B.
4. isType4ProfileOf -- if A isType4ProfileOf B, then instances of A meet a subset of requirements in B, and A adds additional requirements from other specifications that are not incompatible with B.
5. isType5ProfileOf -- if A isType5ProfileOf B, then instances of A meet a subset of requirements in B, and A adds additional requirements from other specifications that may be incompatible with B.
6. uses -- if A uses B, then instances of A meet one or more requirements of B. This is a generic statement that would subsume the other relations (above)

The transitivity rules could be constructed here, but they're tricky.
If A isType1ProfileOf B and B isType1ProfileOf C then A isType1ProfileOf C, is true.

If A isType1ProfileOf B and B isType4ProfileOf C then A isType4ProfileOf C is true...

[kcoyle]

@smrgeoinfo I really like your typology here. It is complementary to the more general statement of typology that I was suggesting for the guidance document. This is the best description of both profile types/relationships and transitivity that I have seen so far.

It seems to me that we have two threads going on that are parallel but have different audiences. One is the world of profiles that exist mainly as documents, such as MS Word documents and PDFs. One could say that these are "old-fashioned and out of date" but they still exist in many communities and are an active part of the community data sharing. Obviously, they require a large amount of human capital to understand and use. They also lack precision, but it is often the case that the data these communities work with is not very conducive to precision. You find this kind of data in the cultural heritage area (libraries, museums, archives) as well as in the crowd-sourcing and open access area as in Wikipedia, MusicBrainz, etc. If you profile within these arenas, you're working with messy data and not much precision. This is similar to the environment that schema.org operates within. These communities can generally go no further than your type 6 in terms of relationships between profiles when they create them.

The other thread is what I would call "precision data" - where closely-aligned communities with a good degree of control over their data and data formats can have reasonably strict rules that can be modeled as formal constraints. These are your 1-5 types. As evidenced by the length of these two paragraphs, my experience is almost entirely in type 6. ;-) However, I see an opportunity here to align these types and provide guidance regarding the profile description elements that are needed to make these types functional. This mainly becomes a definition of this thing called "requirements". I'm interested in whether we feel we can tackle that in our document.

There have been statements that profiles of the type 6 are "useless" or simply do not work. I hope that we can rise above such judgments because we have many real world instances of folks using those types of profiles even though they are not easily subjected to algorithmic validation. We do need to include both worlds in our analysis and deliverable. The trick is going to be how we integrate the two into a single document, but I'm very encouraged that your analysis here may help us navigate that difficulty.

[rob-metalinkage]

@kcoyle indeed using the word specification doesnt add anything really which is why i guess no one felt the need to add it originally - but you were also stating that you couldnt readily see the recursive nature which supports both hierarchies and polymorphism inherent in this definition.

It is of course explicit in the profiles ontology - which is another reason a formalism is so crucial to have IMHO

prof:Profile rdfs:subClassOf dct:Standard

[rob-metalinkage]

I am strongly not in favour of creating a formal typology of profiles - I have seen how much pain, confusion and fruitless debate even two levels in the ISO typology of profiles causes.

If a single conceptual model is able to handle all the cases, then lets keep it simple unless we have a driving requirement that cannot be met with that model - for example some restriction that types of profiles need to express that need users to have provided an explicit statement of type, that cannot be directly inferred trivially from the available properties.

To introduce a typology we would need: 1) driving Use Cases 2) worked examples 3) someone willing to do all the work of modelling, documenting and illustrating 4) a significant debate and proof these things are indeed disjoint.. or at least different enough to be interesting

for example isType3ProfileOf -- if A isType3ProfileOf B, then instances of A meet ALL requirements in B, and A adds additional requirements from other specifications that are not incompatible with B.

is actually the simple case:

A isType1ProfileOf B,C,...

and "requirements" that do not have mandatory cardinality (in the case of information schemas) can be met by absence, so "ALL" is easily met - and if you do not meet requirements you are simply not a valid profile.

At this stage "partial conformance" is out of scope - profiles support the simple case. IMHO its a separate (and difficult) piece of work to work out what a partial conformance statement would mean in a Web context - its difficult to see any useful role beyond making documentation a little easier - "this thing is a bit like one of these"

[rob-metalinkage]

@smrgeoinfo Of course - if you wanted to model different types as constraints you can do this using the profiles ontology -

e.g.

:type1Profile rdfs:subClassOf prof:Profile ; rdfs:subClassOf [ owl:restriction owl:onProperty prof:profileOf owl:maxCardinality 1 owl:minCardinality 1 ] rdfs:comment "a type1Profile is conformant to all requirements of its parent profile related by the profileOf property and introduces no other requirements from other specifications" ; .

But I still fail to see how a client would take advantage of a typology. Its more important to deal with this in the implementing artefacts - finding a language expressive enough to allow constraints to be overridden. Something like SHACL, you simply include the rules from all inherited profiles and the resulting rule set is satisfiable. You may delete redundant rules for computational efficiency if you can detect them - but thats an engineering concern not a logical one.

[dr-shorthair]

I think I agree with @rob-metalinkage 's aversion to a specific typology. As soon as you do that an additional case will appear that does not quite fit. However, some enumeration of styles of conformance is helpful.

The OGC work that we did 10 years ago emerged slightly uneasily from two underlying ideas:

1. Core and Extensions - a small footprint core to which additional capabilities are added
2. Constraints over a very generic model.

The idea to focus on requirements and tests seemed to be the only rigorous way to address this. And then the idea to packages groups of requirements and tests into 'conformance classes' was a principled yet pragmatic way to tame the resulting combinatorial explosion and concomitant challenge to interoperability.

The conformance patterns that @smrgeoinfo describes above cover both these drivers.

[kcoyle]

Typologies can be illustrative, and we may wish to use some if we talk about conformance and transitivity in the guidance document. (We do not yet know if those concepts will be included; we have quite a ways to go in that document.) They may also be useful to explain transitivity in the profilesOnt document. Without some clear examples it may be unclear to readers what the intention is with this function.

@rob-metalinkage Rather than declare "partial conformance" out of scope, it would be good to open a dialog about that with others. That would favor developing a consensus around any decisions, and decisions do need to be the result of consensus. If the group decides that profileOnt will not support that, it would be good to make that explicit and show motivation for the decision. This is not needed for the FPWD, but should be in our sights for the final document.

[rob-metalinkage]

@kcoyle I havent unilaterally declare anything in or out of scope - scope is defined by Use Cases and requirements and consensus processes. So i was pointing out what you have rightly insisted previously, that we need to have these before we can bring this into scope.

That said, illustrative text that is consistent with what is currently in scope can always be proposed and accepted on its own merits. We need the text proposed in the relevant issue so we can vote on it and then an editor can include into the documents.

[rob-metalinkage]

and for the record, I would be more than happy to accept or propose an update to the profiles ontology to handle any requirements that emerge. At this stage its "feature complete" against known requirements modulo a couple of open issues.

[dr-shorthair]

Typologies can be illustrative

+1 absolutely. But care needed around anything that might be taken as complete or exhaustive.

[smrgeoinfo]

So, back to the original question-- is profileOf transitive? If yes, how do we handle the kinds of intransitive relationships implied in my typology discussion above. In the kind of not-formal profile usage @kcoyle discussed, transitivity is probably not a useful concept. The easy solution in the KISS vein is to say profileOf is not necessarily transitive.

[rob-metalinkage]

profileOf is transitive (current model), because profile conformance is a declarative statement, and clients do not necessarily need to be able to test this, or even access a description. Obviously profiles SHOULD have descriptions, tests etc but we can't mandate it. We can mandate the semantics of transitivity however - clients can at least know (that they have been told if not in fact) that conformance to a sub-profile infers conformance to all its transitively referenced parents.

Its important we dont get sidetracked again yet here - this is the logical model we are talking about - implementations (which can be linked artefacts available from the the logical profile expressed using the Profiles ontology) may choose any mechanisms they like to express or hide this transitive logical relationship.

[smrgeoinfo]

I suggest you add a statement that "conformance to a profile infers conformance to all its transitively referenced parent specifications." to the definition of profile. (slightly wordsmithed version of "conformance to a sub-profile infers conformance to all its transitively referenced parents.")

[rob-metalinkage]

That works for me... This is something we need a general consensus on - and affects all deliverables - so I guess best process to create a new issue for this specifically and solicit feedback then vote in plenary.

[nicholascar]

We may wish to provide a tool that looks up through a profile's hierarchy and finds any ancestors' Resource Descriptors with role of Full Constraints in a particular format/spec (e.g. SHACL in an RDF format) and then applies all of them to an instance wishing to validate compliance to the profile. This then would be the full test of conformance to a profile "and all it's profileOf ancestors" and would avoid the requirement for profiles to be "flat". A simple SPARQL query to find any such assets and then a graph merge on all SHACL Resource Descriptor artifacts and execution of them, for which we can use pySHACL.

We may think of validating GeoDCAT-AP instances in this way using DCAT, DCAT-AP & GeoDCAT-AP validators. We may have to fudge things by removing any flattened content within the inheriting profiles for purposes of demonstration.

[kcoyle]

"profileOf is transitive" - If profileOf is transitive, what is the purpose of profileOfTransitive? Or have we gotten confused through all of the various ideas that are floated here?

[agreiner]

I see no reason to assume transitivity is true for all profiles. In fact, I suspect a common reason to make a profile is dissatisfaction with some piece of a parent profile. If one wants to say that datasets that use a profile also conform to a parent profile, would it make sense to use conformsTo? Strictly speaking, it's the dataset that conforms, but maybe we could allow profiles to have a property like ensuresConformanceTo.

[kcoyle]

@agreiner This is why I like the idea of something with semantics like "isBasedOn". Basing on a profile or vocabulary may not equal conformance to that profile/vocabulary, especially in fairly heterogeneous environments. The only other option I see is to say that such "based on" profiles are not really profiles, and that the definition of a profile requires conformance to one or more parents. However, I think that goes against a fairly common use of the idea of a "profile" and would probably cause confusion.

[rob-metalinkage]

read the description of the property and the document - its quite explicit.

[agreiner]

I don't mean that all profiles would have an ensuresConformanceTo, only if they happen to do that.

[rob-metalinkage]

@greiner - as above feel free to crate UseCases where conformance is not expected. We need to distinguish and support conformance as per current model - so we must not break that, but another ontology to describe flavours of non-conformance could be defined. Until that is articulated, tested and evidence of implementation available we cannot break the useful, strict, model that matches the Use Cases we have, and engineering practices across multiple platforms. There is currently no equivalent to isNearlyA predicate available in RDF, OWL, XSD, Schematron, Java, javascript, python etc etc that I'm aware of, although SKOS provides "closeMatch" - so you could use that to relate profiles that are similar without breaking the model.

[kcoyle]

I don't think it makes sense to have a formal definition of non-conformance much less types of non-conformance. And note that the XSD, Schematron, OWL, etc are generally relations between instance data and a profile, not between profiles. So let's stick with relationships between profiles.

To me the issue isn't how we define non-conformance but how we can talk about profiles without conformance. If "profileOf" requires conformance then we cannot say that profileA is a profileOf standardX unless the profileA defines conformance formalisms. Meanwhile, we've floated the idea that a profile can be any combination of functions, not all of which support conformance. So the issue that I see is not whether conformance between profiles is an option, it's whether we require conformance for something to be a profile. And if something like the DCAT-AP PDF can be considered a profile, can it be used as the subject of profileOf? If it is, then what happens to the conformance requirement? These are pretty factual questions.

[rob-metalinkage]

I dont think it makes sense to talk about specifications or standards or profiles without an assumption of conformance. Anything else confuses and complicates the issue immensely, and until we bring it into scope using the established consensus mechanisms it remains out of scope.

[makxdekkers]

Been away for a couple of days so coming in late to this discussion. One point that we discussed with the implementers of the EU DCAT-AP was how implementers could create national/local profiles of DCAT-AP. We talked about such local profiles 'extensions of DCAT-AP' and published a guideline for such extensions: https://joinup.ec.europa.eu/release/dcat-ap-how-extend-dcat-ap. The basic idea was that instance data conforming to a local profile would also conform to the European profile, so that instance data from one country would still be able to interoperate with instance data from another country that conformed to another country's extension -- but they might not understand each others' local bits. It would be useful if such a local profile could express this kind of relationship between the local and the higher-order profile. Would this be a type 3 relationship as defined by @smrgeoinfo?

[nicholascar]

@kcoyle “...if something like the DCAT-AP PDF can be considered a profile...”

According to Profiels Ont it wouldn’t be, it would be the artifact of a Resource Descriptor. See the on point example: https://w3c.github.io/dxwg/profilesont/#eg-dcat-ap

And I back @rob-metalinkage up too: it makes no sense to talk about profiles without any conformance. That is what they are for.

@makxdekkers see the on point example at https://w3c.github.io/dxwg/profilesont/#eg-hierarchy

[kcoyle]

It seems clear to me that DCAT-AP considers itself an application profile, without specifying any particular implementation of conformance:

"The Application Profile is intended to facilitate data exchange and therefore the classes and properties defined in this document are only relevant for the data to be exchanged; there are no requirements for communicating systems to implement specific technical environments. The only requirement is that the systems can export and import data in RDF in conformance with this Application Profile."

The use of "this" in that last sentence appears to refer to DCAT-AP as an application profile (not to mention that it's in the name!). So if we agree on the reading that conformance is assumed but not defined, then DCAT-AP can call itself a profile while being a PDF. Conformance implementation can take place elsewhere or even be unknown to the profile, and it does not have to be co-existent with the profile specification. (I would like to hear from @makxdekkers on this - did I get this right? Or would you like to clarify this? Thanks.)

If that is agreed, then profileOnt provides the way to make the connection between the profile specification and the profile conformance in the case in which they are separate resources.

Note also that your diagram has a DCAT-AP box that has "profileOf" between DCAT-AP and DCAT. If the DCAT-AP there is not the DCAT-AP that has as its title DCAT-AP then the diagram is misleading. I think we have a lot of definition issues to work out.