Axiomitise transitivity of dct:conformsTo through isProfileOf relationships

[rob-metalinkage]

Based on the normative text,

:aResource dct:conformsTo :Profile1 . :Profile1 prof:isProfileOf :Profile2 .

entails: :aResource dct:conformsTo :Profile2 .

we can add an OWL axiom to formalise this entailment - i think it would look like this

dct:conformsTo owl:PropertyAxiom ( dct:conformsTo prof:isProfileOf)

Can we confirm this is correct and if so vote to include it in the normative ontology and description?

[nicholascar]

It is critical that the issue of the isProfileOf/conformsTo relationship be formalised, not that it be done so as suggested above.

[aisaac]

The suggested axiom seems the most natural one, especially considering the vagueness of the definition for conformsTo. And I think I've recently supported this. That said, I'm puzzled, as I'm not sure it would apply to everything that I think is a profile of something else in the Europeana context. Anyway, I don't have the time to dig up now, and I think it is worth bringing this to the group. If anyone has concrete counter-example that invalidate the axiom, this would be very useful for the discussions we're having across the board on what profiling means.

[kcoyle]

We've been around the block on this one more than once. (#507, #660) The problem here is what "conforms to" and "profile of" mean. What happens when I have one profile with A, B, and C properties, and profile of that profile that has properties A, B, C, D, E? This is the case with the DCAT-AP variations that I have seen. Doesn't conformance depend on what the profile creators says is conformance? A validation schema that is coded for the former profile would not validate the latter if the profile is seen as "closed" (does not allow unlisted properties). What if one profile says A is required and another says A is optional? Does that mean that they can't say that one is a profile of the other?

Unfortunately, we need to resolve the questions brought up here and in the other issues. I don't see anything "axiomatic" yet in how these two properties are defined.

[makxdekkers]

@kcoyle

"conforms to" and "profile of" mean. What happens when I have one profile with A, B, and C properties, and profile of that profile that has properties A, B, C, D, E? This is the case with the DCAT-AP variations that I have seen.

From what I know of DCAT-AP and 'extensions' like national DCAT profiles, those 'extensions' are not presented as profiles of DCAT-AP, but rather as profiles of DCAT that are compatible with DCAT-AP. See the rules established for such extensions: https://joinup.ec.europa.eu/release/dcat-ap-how-extend-dcat-ap. I would say that those profiles are 'compatible with' rather than 'profiles of' DCAT-AP.

[aisaac]

@kcoyle it makes perfect sense to discuss this in the other issues, for finding out what isProfile and conformsTo mean. As I've said, if the discussion there leads to counter examples, then they can brought in the discussion here. So @makxdekkers 'comment would be a better fit for #507, maybe. Same as @kcoyle 's remark on what conformance means: this is probably for #660 . But I think talking with A,B, C, D, E is good though, because this is the kind of thinking that would help us judge whether the axiom is true (with input from discussions in other issues). I'm sorry this probably looks very pedantic a comment, but I think we must really implement what @kcoyle suggests, and try to have these various bits of discussion in the issues where they are relevant!

By the way maybe we're partly misunderstanding each others' intentions here, when you conclude with "I don't see anything "axiomatic""? The matter of the issue is about axiomatizing in the sense of "formalizing semantics as (OWL) axiom". Therefore suggesting an OWL axiom is a valid proposal for the issue - even if one would disagree with this axiom.

[rob-metalinkage]

Also, there is no real reason why we can't specify one set of semantics and if it doesnt fit some cases thats just tough. These cases have not been specified in sufficient detail in the UCR process for anyone involved to tease out a requirement for anything else for what "compatible" may mean that is different from a valid use of "conformsTo" - though of course such cases may exist.

Making semantics so vague it says nothing that supports inferencing is not a useful way forward - unlike specifying a simple semantics that doesnt obviously fit some cases for we can't quite nail down what the semantics might be. (i.e. can we propose a set of axioms that are true for these cases that also support the key competency questions we have identified about conformance? If so - lets see if that gives us more power and flexibility, if not, then we go with the scope we can understand and if it needs more work to apply to some cases in future so be it.)

[aisaac]

Having vague semantics can be a way forward, as per the "minimal ontological commitment" design principle (and cf "Best Practice 16: Choose the right formalization level" in earlier W3C work). I believe PROF can be useful even if there's no axiom on conformsTo/isProfile of. But indeed, if there can be such axiom (i.e. there's no objection to it, based on the profiles we see out there), then it's nice to have it.

[rob-metalinkage]

@makxdekkers the example you cite is rather informative - but it supports the view in the profiles vocabulary rather than any suggestion that we need some weaker notion of "compatibility" to handle DCAT-AP profiles.

" Extensions must not widen but may only narrow down the usage notes as specified in DCAT-AP v1.1, so that all information provided according to the extension remains valid for DCAT-AP v1.1"

and if you wanted to argue about "thats for extensions not profiles" it makes it clear it regards these as the same in the rationale:

"The proposed rules are intended to allow an extension profile to satisfy local or domain-specific requirements while preserving interoperability in a wider European and cross-domain environment,"

this neatly joins the dots in the proposed Profiles design that its notion of compatibility via conformance is a requirement for interoperable data exchange.

[smrgeoinfo]

Given that the interpretation of dct:conformsTo is fuzzy, will vary from specification to specification, I think the proposed entailment is good because it conveys the intention of the 'profileOf' relation that distinguished it from other relations between specifications.

[makxdekkers]

@rob-metalinkage @smrgeoinfo Are you saying that the kinds of rules specified in https://joinup.ec.europa.eu/release/dcat-ap-how-extend-dcat-ap are implied for the prof:isProfileOf property? I don't see that in the definition or usage note at https://w3c.github.io/dxwg/profilesont/#Property:isProfileOf. I read: "All constraints of these specifications are inherited, in the sense that an object conforming to a profile conforms to all the constraints specified the targets of prof:isProfileOf relations" (something wrong with the sentence) which to me says that a national DCAT profile is not allowed to change constraints of DCAT-AP, not even to relax or widen the scope or change cardinalities. If such a set of rules is implied, maybe this should be made explicit.

[smrgeoinfo]

I think there's a problem with the interpretation of the term 'inherited', which I would understand (and it seems that you do as well) to mean the exact constraint rule applies. This is not consistent with "an object conforming to a profile conforms to all the constraints specified the targets of prof:isProfileOf relations", which if I understand how to extent dcat, is consistent with the rules presented there, and with the axiom @rob-metalinkage proposed at the top of this issue.

The simple solution I'd propose is to revise the usage note to read "An object conforming to a profile conforms to all the constraints specified the targets of prof:isProfileOf relations"

[rob-metalinkage]

If you conform to a narrower condition you also conform to the broad condition, so there isnt actually any difference in these interpretations of inherited...

This is why axioms are important - they are unambiguous and not subject to different people's preferred way of interpreting common words. Given that the definition provides a very explicit way to interpret the usage of "inherit" IMHO it is useful in that it then allows us to refer to this behaviour with a single word anytime we need to, rather than repeat the full clause every time it applies. That said, if someone wanted to review the text and do a PR to make sure that we have the simplest and cleanest way of referring to the functional requirement everywhere we need to we could drop the "binding" to a term.

there is a missing word - > specified BY the targets

but no doubt people will also confuse targets with conformance targets at some point, so we could be more RDF -y and say "objects"

so it would read "specified by the objects of isProfileOf relations"

[aisaac]

Well actually I have just today made a suggestion to remove considerations of inheritance and conformance in the usage note of prof:isProfileOf, as it pollutes the discussion on semantics here, and it should probably be factored in a specific section, not spread across various bits in PROF. And it gives a bias: if we decide to follow what's in this note already, then the discussion here is moot, as indeed there can be almost no debate about the formalization of it :-)

Coming back to formal axioms: the one currently on the table states that if A is a profile of B, and a dataset D conforms to A, than D should conform to B. Let's replace A by "an extension of DCAT-AP", B by "DCAT-AP", assume that "extensions" in DCAT-AP can be captured by our notion of profiling, and see whether the proposed axiom holds in the DCAT-AP context. I understand that the "recommendations" in @makxdekkers ' document imply that an extension of DCAT-AP should never introduce conditions/constraints/recommendations/whatever that makes it possible for data conformant with the extension to be non-conformant with DCAT-AP itself. (NB: the document uses the word 'minimal conformance' but I fail to see other kinds of conformance for DCAT-AP). So this seems to fit the intention of the axiom!

[kcoyle]

@aisaac I can see that DCAT-AP and its recommendations for extension fit this model. Does that mean that EVERY profile that is a "profile of" fits this model? Are we describing a tautology, such that: if it fits this model then it is a "profile of" the related profile? DCAT-AP has a pretty comprehensive description of rules for extension, but I'm not at all sure that we can assume that all profile "families" adhere to these same rules.

[rob-metalinkage]

So far we think all the identified motivating use cases ( including DCAT-AP, ISO, OGC, Europeana. Conneg (abstract model), media type profiles ) fit this model and we have no examples of cases where we can show it doesnt or that something useful would be gained by modelling a different behaviour...

so lets leave it as is, and that's the scope of this model and its definitions. Others could come along later and declare a superclass with relaxed semantics to handle other cases if they feel the need - either as a upgrade to this ontology or a new one aligned to it.

[agreiner]

Let's not forget the case where a profile is a profile of more than one specification. In that case, it is possible that the base specifications conflict in some use of terms. It would obviously be unwise to make a profile that includes conflicting terms, but a profile might use terms that do not conflict with each other but that come from base specifications that use other terms in conflicting ways. One example that I recently came across is the use of DCAT along with a domain-specific data specification. I met a researcher who is interested in mixing DCAT with NeXus. Fortunately, NeXus prefixes all its terms with NX, but if the user had chosen a vocabulary that did not do that, conflicts could have arisen. In my view, it would be the job of the profile to select which terms from each vocabulary are used and to ensure no conflicts exist for data conforming to the profile, but I would not assume that conformance to that profile means complete conformance with the entirety of each base specification. I would, however, assume that data that conforms to the profile also conforms to each base specification's requirements for the terms borrowed from it.

[aisaac]

@kcoyle yes indeed we can't assume that all profiles fit these rules. But I would say that here it's fair that the burden of proof falls on the contradicting side: we just need one legit counter-example to prove the axiom wrong.

Btw I'm not sure that the Europeana Data Model rules fit the axiom. As said earlier I just didn't have time to check it further. But I feel that @agreiner may be on a good interpretation of what happens in the Europeana context. The one example that comes to mind now is the DPLA application profile. It is "based on EDM" as it re-uses quite some vocabulary elements from EDM (themselves inherited from other vocabularies) and some key patterns. But for one key type of resources it uses its own class (dpla:SourceResource) which differs from the EDM one (edm:ProvidedCHO) therefore most of DPLA's metadata record wouldn't qualify for ingestion in Europeana. There would be a data conversion (albeit a simple one) to run first.

[kcoyle]

I guess it depends on what is considered a contradiction. In BIBFRAME, anyone can create a profile that uses a different vocabulary list for the value of things like subject or material type. And the profiles for specialized formats do that. While there is no actual mechanism for profiles of profiles, two profiles that are profiles of BIBFRAME can be compatible with BIBFRAME but not compatible with each other. So I guess it depends on whether this axiom is limited to profiles of profiles. If so, stating that clearly in the document would be helpful.

[nicholascar]

@agreiner seems to be describing something that's more akin to owl:imports or the voaf:uses than what prof:isProfileOf is intended for.

We can interpret prof:isProfileOf strictly - it's all about conformance - and then describe other ways in which specifications may relate that are not conformance relations.

[agreiner]

owl:imports or voaf:reliesOn, voaf:specializes and friends seem like ways to encode a profile that works for the use case I describe, but I don't see how that makes it not a profile.

[aisaac]

@kcoyle "two profiles that are profiles of BIBFRAME can be compatible with BIBFRAME but not compatible with each other." is not a contradiction to the axiom. This is a formal axiom that states "if A is a profile of B, and a dataset conforms to A, than this dataset should conform to B" It can be contradicted if you can find any specifications A, B, such as A is a profile of B and there can be a dataset that conforms to A and not to B. No need to find more complex situations: just find an A and a B for which that holds. In my putative case, A is DPLA MAP and B is EDM.

@nicholascar interpreting prof:isProfileOf in a way narrower than what is hinted by the current definition of profiles would be cheating :-) Or well , one could try this, but then this one's duty should rather be to create a sub-property of prof:isProfileOf for which the axiom is true - leaving it open to use the unconstrained, more general property for other types of profiles.

[rob-metalinkage]

I dont see a counter-example in "is based on" cases - its either "based on but not a profile of" (prov:derviedFrom of something) or the community defines its notion of conformance around whatever it needs to interpret "based on" in some functional behaviour.

I think we should be happy just to provide the missing mechanism for describing strict conformance and leave other less easily described behaviours alone.

[rob-metalinkage]

@agreiner - some other "uses" relationship can handle cases where terms are used but conformance to a "base" is not. If you import that base in OWL imports of course you buy every restriction in the base - so if you conform to OWL semantics you conform to the base.

generally simple vocabs without OWL axiomitisation introduce just one type of constraint - if you use a term T then you honour its datatype and semantics...

all RDF vocabs also conform to the RDF specification at a low level - the same is true for every encoding - so whilst it would be technically correct to describe these using dct:conformsTo obviously nobody would and there is a more specialised relationship (dc:format) that states the same thing for the encoding aspect only. So - its a matter of community choice whether to include common base vocabularies in the statements of conformance they wish to make.

[aisaac]

@rob-metalinkage indeed @agreiner 's owl:import would be a case where the axiom works indeed. But the other types of profiling are more dubious.

Of course the question is whether these "is based on", as you say, would qualify as profiles, or more precisely, would make acceptable occurrences of prof:isProfileOf statements. This is perhaps more in scope for #507 and I'm going to add a comment there. But I do believe that my case does fit the definition we've agreed on for data profiles "A data specification that constrains, extends, combines, or provides guidance or explanation about the usage of other data specifications."

Note that #507 had a comment from @agreiner hinting that prof:isProfileOf could be likened to a note in the documentation for a profile. As said there I was tempted by that. This would support the idea of not having the axiom applicable for prof:isProfileOf per se, but apply it to a specialization of it that would carry a more rigid conformance requirement.

[kcoyle]

@aisaac If "profileOf" must have as its subject a profile and as its object a profile, which I think is the case, then that should be stated clearly in the document. In the past there were statements like "X is a profileOf Dublin Core terms" which is not true if both subject and object must be profiles. The axiom does show that both subject and object are profiles, but the definition of "isProfileOf" is:

The subject of 'is profile of' defines constraints on the object which playes the role of a base specification

So it talks about a base specification, which could be something that is not a profile.

[smrgeoinfo]

seems like the object should be a specification, maybe dct:Standard?

[nicholascar]

Straight outa PROF 2PWD (https://www.w3.org/ns/dx/prof/):

:isProfileOf rdf:type owl:ObjectProperty ;
           rdfs:domain :Profile ;
           rdfs:range dct:Standard ;

[kcoyle]

OK, so this "axiom" is more specific than the definition, because the axiom shows two profiles, not a profile that is a profile of any standard. To my thinking that requires a different axiom:

:aResource dct:conformsTo :Profile1 . :Profile1 prof:isProfileOf :someStandard .

entails: :aResource dct:conformsTo :someStandard .

This is also quite a more more ambiguous since "someStandard" can be just about anything. If we are creating an axiom it should be consistent with the definition of the properties; after that, examples can show the variety of things that also meet what the axiom defines.

[nicholascar]

@kcoyle I agree with your characterisation above I'm not quite sure I follow your statement

the axiom shows two profiles

If you're referring to Rob's starting comment containing :Profile1 & :Profile2 text of:

:aResource dct:conformsTo :Profile1 .
:Profile1 prof:isProfileOf :Profile2 .

entails: :aResource dct:conformsTo :Profile2 .

well that's just example text using individuals of :Profile1 & :Profile2 informally. So, despite perhaps awkward naming since, as you note, there's no hard requirement (in the vocabulary) for :Profile2 to be a profile as opposed to a dct:Specification, there's consistency between what you suggest above and his example.

In the next PROF meeting, I hope to check that the descriptive text and examples matche the axioms.

[rob-metalinkage]

much of the same ground has been covered in #802 - which is a "discussion only" issue with no resolution - the resolution of this issue will determine whether isProfileOf owl:equivalent dc:relation (some relation but it is not specified what it means) or whether it has useful semantics that allow entailment of conformance statements as defined by the property axiom proposed.

[aisaac]

@rob-metalinkage as much as my case may require not having a tight axiomatization for prof:isProfileOf, I reckon that prof:isProfileOf owl:equivalent dc:relation is just impossible. dc:relation is a super-property of many DC elements, and the suggested axiom would imply that these properties would then be also sub-properties of isProfileOf. Some of them may fit (e.g. for dc:references, maybe we can say that a profile of another spec references that spec). But for some of them this doesn't fit: dc:replaces or dc:hasFormat clearly can't be sub-properties of prof:isProfileOf, even with a wide interpretation of prof:isProfileOf.

[aisaac]

@kcoyle @nicholascar I guess we can agree that the suggested axiom should be rewritten with something like :baseSpecification instead of :profile2 . It doesn't change anything to what @rob-metalinkage has proposed but it would avoid unnecessary discussion whether :profile2 was a "true" profile or just any spec.

By the way @rob-metalinkage @nicholascar can we stick to the convention that instance ids should start with lower-case and class-ids with upper-case?

[agreiner]

I believe we discussed long ago the validity of having more than one base specification for a profile. Because those base specifications have a possibility of disagreeing on something, even if only one specification's approach to any conflicting term is used in the profile, it is not logically possible to claim that what conforms to the profile must conform to the base specifications. It might be helpful, however, to state conformance when that is the case.

[rob-metalinkage]

@aisaac - i think you mean the example - not the axiom? If so fine.

I agree making profileOf have no specific relation semantics doesnt make sense and just entails "everything is a profile" which is clearly unhelpful - which is why we can focus on the specific case where profileOf is transitive and has a semantics as strong as "dct:conformsTo" - which is actually fairly loose.

@agreiner - if base specifications disagree on something - then its up to a use community to define a loose enough notion of conformance these statements can be made - otherwise, irrespective of labelling, those resources do not conform to the modelled semantics of profileOf. If I wanted to state my car is a lemon it doesnt mean I have to redefine the "functional" notion of lemon in a fruit market.

[rob-metalinkage]

Discussions have been about how to describe the looseness of dct:conformsTo semantics and the fact there may be cases where conformance is not transitive that are out of scope for this model and not evidenced strongly enough or early enough to consider supporting.

It seems that the intent can be clearly stated axiomatically, and that this is necessary to help understanding. So I propose we add the following statements and matching text to the .ttl file and document:

• state that things conform to profiled specifications if they conform to a profile dct:conformsTo owl:PropertyAxiom ( dct:conformsTo prof:isProfileOf) .

• to document that profiles imply conformance to any profile in the declared profile relationship heirarchy. prof:isProfileOf a owl:TransitiveProperty .

In conjunction with clarification text that communities may determine what "conformsTo" means in their application scope, these axioms allow useful statements to be made - without that ontological commitment then just use dct:relation or some other vocabulary and rely on interpreation. No other relationship vocabulary was identified that supported these semantics. hence the rationale for publishing a new vocabulary with these specific semantics.

[agreiner]

There's no reason for the community to harmonize differences among base specifications for terms not used in the profile. The value of the profile in this case is that it allows them to use what is helpful for them from each base without being saddled with the bits of each base that cause them headaches.

[rob-metalinkage]

@agreiner if we are talking just about selective term re-use then its not appropriate to describe this as profiles with this vocabulary - which is perfectly fine as the vocabulary supports a different need. (unless some definition of "conformance" is adopted by that community, which is also compatible with the requirements in the base specifications, which allows statements of conformance to be made transitively. ) As a guide I suggest you consider the implications of RDF 2119 - MUST vs SHOULD etc - if you are talking about requirements that dont have to be met that will be a really interesting problem to model and define - and not within scope here.

[aisaac]

@rob-metalinkage yes I meant the example.

And the comment "there may be cases where conformance is not transitive that are out of scope for this model and not evidenced strongly enough or early enough to consider supporting." could be a way forward.

But not for cases that are part of our use cases and requirements. And not for situations (partial vocabulary re-use) that seem to be in scope of our definition for profile definition or for our charter (which sees application profile as a way to handle the issue that "no single vocabulary offers a complete and universally accepted solution."). I reckon that there was a discussion on whether vocabulary-reuse counts as profiling, and how much re-use would be needed for the re-use to qualify as profiling. I'm not sure where the issue was (there are too many of them!). But if the issue has not be decided on by consensus, then we can't dismiss @agreiner 's case and mine this easily.

[nicholascar]

This axiom has been added to the ED, see https://w3c.github.io/dxwg/prof/#Property:conformsTo. I will close this issue since the title problem has been addressed and follow-on topics can generate new issues.