Dxwg: What does prof:profileOf entail?

[kcoyle]

Copying discussion from #486: Karen, Rob, Karen, Nick, Karen. The basic question is: when one uses profileOf, as in "X prof:profileOf Y" what is entailed from Y when working with X?

[kcoyle]

As profileOf has a range of profile, is it only to be used for profiles of profiles?

[rob-metalinkage]

ah - i think we could make the range dct:Standard or axiomitise the entailment

X a dct:Standard
X prof:profileOf X (the "null" profile)

i prefer to relax the range.

[aisaac]

I was just about to comment about relaxing the range, so it's going to be a +1 on this one :-)

And about the semantics I'm not sure there should be much semantics put at this stage. Maybe once we've got all requirements considered... But for now I'm unsure about implications of what 'profile of' could mean. We've got different kind of profiles, and each of these types may imply a different type of 're-use' of elements.

In fact 'profile of' seems to me like a generalization of 'uses' between Descriptions Set Profiles and Metadata Vocabularies in the DC Singapore Framework (http://dublincore.org/documents/singapore-framework/) where 'uses' could be also employed in a recursive manner between a DSP and another. @kcoyle has there been any detailed semantics for what 'uses' mean there?

[kcoyle]

@aisaac From what I can tell, the DSP did not include the Singapore Framework relationships, so "uses" was not defined there. In SF, the relationship between a profile and vocabulary is defined:

"Description Set Profiles typically use properties and classes defined in standard Metadata Vocabularies such as the DCMI Metadata Terms."

This says to me that there is a specific relationship ("uses") between a profile and a base vocabulary. DCAT-AP "uses" DCAT, and that sounds very much like profileOf. Personally, I'd favor a property or at least a description that very broadly means "based on" and that would only be used when there is a strong link between the vocabularies, like the relationship between DCAT and DCAT-AP. I would like for profiles to be able to be "stand alone" as well, since I think those happen. The discussion at #435 seems relevant here.

Note that there is an ambiguous aspect to the Singapore Framework that means that by its definitions DCAT itself could be developed as a Dublin Core-defined profile. I think we in DC need to clarify that.

[aisaac]

@kcoyle thanks for the clarification. So 'uses' is not so much specified in DC. Which is fine by me. We probably need a relation that is quite abstract. And then we may need specializations with stronger semantics, to answer more specific requirements and the various motivations for profiles you've raised in #435 (indeed it's relevant here!)

In any case I think we should first agree that 'profile of' is the most generic relation...

[pwin]

daft laddie question: if we are relaxing range of prof:profileOf then shouldn't we make the classes (e.g. Profile and ResourceDescriptor) disjoint?

[nicholascar]

This would follow the DCAT Dataset/Distribution disjointness I suppose? Depends on how much relaxing is going on! If relaxation to dct:Standard (my preference as this then allows profiles of standards and other profiles) then this wouldn't be needed although it might be a good idea anyway.

[nicholascar]

Range of profileOf and profileOfTransitive relaxed from prof:Profile to dct:Standard (of which prof:Profile is a subClassOf) in commit https://github.com/w3c/dxwg/commit/be299e465b76d99a2a36c1df681840bbed15dbbd

[kcoyle]

Great, thanks Nick. Now we need to understand how we are defining profile and how we are defining profileOf in relation to profile. These may need to depend on clarifications in the guidance document, but this seems to me to be a strong interrelation between the ontology and the guidance document, and we should keep both in mind while working.

[riccardoAlbertoni]

I think this discussion might also relate to issue "prof:profileOf sub-property of prov:wasDerivedFrom" https://github.com/w3c/dxwg/issues/485

[kcoyle]

@riccardoAlbertoni , thanks. I really like the idea of "was derived from" because it allows the derived profile to differ and doesn't force it to be hierarchical. It may be that both are needed in profileOnt to cover both the hierarchical and the non-hierarchical derivations. I also think that "was derived from" is more conceptually similar to the DC Singapore Framework's "uses". It makes a connection without enforcing hierarchy, which is often too rigid of a relationship. #485 suggests that profileOf would be a subproperty of prov:wasDerivedFrom, and therefore further defines the type of derivation. PROV uses types, however, as in "prov:type='prov:Revision'". This seems to make sub-classing of derivedFrom more complex. In other discussions people have mentioned that a relationship between a vocabulary and a profile might be considered an extension. Extension looks to me to fit into a prov:type.

All of this leads me to think that we could (eventually) consider types of profiles. (See comment on types of profiles.) At the moment, one view of profileOf is that it is a hierarchical relationship, but I see it as being more variable.

[smrgeoinfo]

Seems to me a basic problem here is defining 'profileOf', which partly depends on what we want to use this for, see discussion at https://github.com/w3c/dxwg/issues/435#issuecomment-434829948. I think what is useful is to be able to say that for some Profile X of Specification Y, a resource conformingTo profile X also conformsTo specification Y. This requires that there is some conformance test for specification Y. In the XML world, this is done by saying that documents conforming to the profile will validate according to the xml schema (and or schematron rules) for the base specification. In the OGC/ISOTC211 modular specification thinking, one could assert that my new specification (a profile...) requires that conforming resources meet conformance classes 1, 5, and 8 from specification A, and conformance classes 2, 3 and 4 from specification B. That would be actionable information. The problems are that in many specifications, conformance tests are not defined or identified in a way that could be used in a profile definition, and in the rdf vocabulary and JSON world there aren't widely used validation tests for conformance to a spec (SHACL and SHEX, JSON schema are coming along).

[kcoyle]

The other complication is that "conforms to" can be very complex between profiles and vocabularies. That instance data conforms to a profile is one thing. But profiles are by their nature decisions that differ from their base standard (whether a vocabulary or another profile) or else they wouldn't exist. How they differ can be pretty variable - some add constraints, some add vocabulary terms, many drop unused terms from the base, some will do a combination of all three. So "conform" is not a single thing between profiles and bases. This makes "profileOf" rather difficult to define, or at least hard to interpret unless you know quite a bit about the nature of the base(s) and the profile and how they relate to each other. A tight coupling between profiles and bases is not currently the norm in all communities - there's a lot of riffing off of prior resource descriptions but not in a way that can be tested or validated due to the nature of the material being described. Unless we want to limit our work to a strict definition of profile, we need to allow for the way these looser communities work.

[rob-metalinkage]

There is currently NO notion of a relationship "conformsTo" between profiles in either identified requirements or the ontology - this relationship is between data instances and profiles. If there is wording in docs that suggests this it needs to be corrected.

This suggests the "conformance Target" discussions for both profile guidance doc #525 and individual profile descriptions #521 need to be prioritised to improve shared understanding here.

The only relationship between profiles (and base specifications) is profileOf
The issue of "uses" vs "constrains use of" may itself be a matter of conformance targets - what is the conformance target of dublin core?

This becomes very relevant to the "flattening" discussion too - no one ever duplicates every vocabulary they use in a "flat" profile. i.e. they are never truly standalone (nor would they be useful if they were)

So it seems as if practically the transitivity entailment might be exclusive of base specifications - which supports my instinct to model it explicitly in profiles ontology even though no behaviour was yet specified. We formalise this with conditions, or sub-properties ( profileOf subPropertyOf uses ?) I'd be reluctant to rely on explicit statement that something is a "base specification" - everything is built on something and thats a community perspective how deep you need to declare it.

Perhaps we need a section "profile conformance in an open world" - under open world any vocabulary can be used and an instance may conform to any number of specifications without it being significant w.r.t. a given statement about profile conformance.

[smrgeoinfo]

I revised my original comment. The conformance issues isn't about profile A conforming to B, its about resource instance conformance. If there are not testable implications of asserting that some resource conforms to A, which is a ProfileOf B (the basic entailment question that started this conversation), then what is the use of making the assertion? It would boil down to little more than asserting that 'A isRelatedTo B'. Isn't the whole idea that the profile concept can help agents (people or software) figure out if a resource representation is going to be useful for their requirements without having to GET it and feel around?

[rob-metalinkage]

@smrgeoinfo - thanks - that clarification will hopefully help us back out of this rathole :-)

Note that the profiles ontology, which provides an implementation pathway for these concerns, allows us to reference multiple artefacts with different roles - and these roles can include conformance validation - or guidance. They are agnostic of the actual language (none seems perfect and universally applicable anyway), but have a conformsTo property to allow a client to see what language the artefact itself is written in.

I think this addresses your concerns, but please feel free to ask further questions, suggest counter-examples or even suggest improved wording in the relevant deliverable documents as they emerge.

[kcoyle]

@rob-metalinkage said: "This becomes very relevant to the "flattening" discussion too - no one ever duplicates every vocabulary they use in a "flat" profile. i.e. they are never truly standalone (nor would they be useful if they were)."

I disagree with this, and this tells me that we aren't talking about the same thing. A profile lists every property that is _intended_ to be used by users of that profile. Anything not listed in the profile is not used and therefore isn't needed. What IS listed in the profile DOES stand alone. So a profile that includes 2 elements from vocabularyOrPRofile A and 3 elements from vocabularyOrProfile B, and ignores all of the other elements from A & B because they will not be used, is a FLAT profile, stands alone, and does not include the entire vocabularies of A or B.

A profile is not made up of entire vocabularies, just the elements of those vocabularies that are needed in the profile. If an entire vocabulary (or base profile) will be used, the entire thing is duplicated in the new profile.

When you say "no one duplicates every vocabulary" are you thinking that "flat" profiles means that the entire element set from all base vocabularies would have to include all elements of all vocabularies, even if not needed for the profile?

Or are you saying that to be a profile it has to include an entire prior vocabulary or profile?

If neither of these, please explain what you mean above. Thanks.

[agreiner]

Excellent point, @smrgeoinfo! To answer @rob-metalinkage from the other thread, I don't dispute the existence of cases where hierarchical relationships exist between profiles. That is central to the concept of profiles. My concern is that we address real-world use cases for making additional statements about those relationships. I can see that it could be helpful to point out that a certain profile is also a descendant of a significant grandparent profile (like DCAT-AP), if it does in fact meet all the requirements, but I'm not sure that needs to be a property of the profile rather than a note in its documentation.

[aisaac]

@agreiner I think I would rather postpone the discussion on what profileOf entails in terms of conformance until we've finished our requirements. So for the moment I would concur with you that profileOf is at the level of an annotation.
BUT we're trying to enforce best practices in terms of structuring and linking data, so when a note-level bit of data is about expressing that there is a relation between A and B, then it should be expressed as a relationship between two URIs! To me this is the gist of having profileOf as a property now. Whether we name it isBasedOn, wasDerivedFrom or whatever. We need a link between two profile URIs.

[nicholascar]

To be dealt with via a formal statement about competency questions

[rob-metalinkage]

@makxdekkers cited https://joinup.ec.europa.eu/release/dcat-ap-how-extend-dcat-ap which is rather informative - which may not have been the intention when citing it but it supports the axiomitisation proposed in #844

" 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.

[aisaac]

In #844 there's a discussion on whether one example of "profiling" between the DPLA metadata application profile and the Europeana Data Model. The DPLA MAP 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.
The question is whether this accepted use case could be represented with a prof:isProfileOf statement. I believe it should, of course ;-)

[makxdekkers]

@aisaac I think your point makes sense. Just a question, does the DPLA MAP strictly satisfy all the constraints defined in EDM for all the elements it reuses from EDM? If so, I would agree that it is a profile of EDM, because it does not violate EDM.
The case of DCAT-AP extensions is stronger: it also considers the use of 'similar' classes and properties -- of which the dpla:SourceResource as 'similar' to edm:ProvidedCHO is an example -- a violation of the rules. So the relationship between an extension of DCAT-AP and DCAT-AP would need to be a stricter sub-property of prof:isProfileOf.

[nicholascar]

Entailment axiom, usage notes (for dct:conformsTo) and examples added to 3PWD candidate: https://raw.githack.com/w3c/dxwg/prof-3PWD-candidate/prof/

[aisaac]

@makxdekkers good question ("DPLA MAP strictly satisfy all the constraints defined in EDM for all the elements it reuses from EDM"?). I need to check and this is going to take time as there is an avalanche of DXWG stuff in my mailbox...

Re. DCAT-AP extensions vs my case, I'm split: DPLA may have a motivation for including a "similar" class to EDM's edm:ProvidedCHO, when that class is defined as "This class includes the Cultural Heritage objects that Europeana collects descriptions about." It actually allows non-Europeana perspective but the writing is such, that I understand DPLA would want to have a more neutral resource (or, instead, a resource that represents their own perspective).

In any case, DCAT-AP profiles, would be a specific kind of profile. Note that this is probably true, whether we go for my "soft" view of what count as a profile, or a stronger one that would be based on say, DCAT. DCAT profiles rules out classes that are not covered in DCAT, which seems weaker than excluding elements that would be "similar" to what is in DCAT (adapting to DCAT the criterion coined for DCAT-AP at https://joinup.ec.europa.eu/release/dcat-ap-v11)

[kcoyle]

@nicholascar Were there conclusions here that led to updates to the 3PWD? If so, could you say what they were? Thanks.

[rob-metalinkage]

@makxdekkers - excellent point : "So the relationship between an extension of DCAT-AP and DCAT-AP would need to be a stricter sub-property of prof:isProfileOf."

This is essentially correct and natural and the implications are:

1) to have a stricter sub-property we would still need the existing super-property that handles all possible notions of conformance and supports the transitivity needed for conneg and data descriptions.
2) a sub-property could be defined to carry the additional ontological commitment for a specific notion of conformance.
3) we are not in a position to define these sub-properties yet as we have not been engaged in a systematic evidence capture and modelling of notions of conformance.

so I would slightly reinterpret that statement this way:
"the relationship between an extension of DCAT-AP and DCAT-AP would need to be a stricter sub-property of prof:isProfileOf to convey the specific meaning of conformance according to DCAT-AP extension rules, but can be validly described with isProfileOf to indicate that such a relationship exists and conformance to DCAT-AP is required."

[nicholascar]

The question in the title of this Issue, "What does prof:profileOf entail?" is answered by the axiom in the ED, see https://w3c.github.io/dxwg/prof/#Property:conformsTo.

[kcoyle]

I don't see what dct:conformsTo has to do with this. The question here is prof:profileOf, and if it means the same thing as dct:conformsTo then that is what should be used. Those are two different properties. And the question is: what is entailed by "profileOf"? which isn't answered.

[nicholascar]

It answered, but not fully. So far the only claim about entailment is given by the axiom dct:conformsTo owl:propertyChainAxiom ( prof:isProfileOf dct:conformsTo ) such that prof:isProfileOf cains on conformance. What conformance means is not dealt with in terms of entailment, only the DCT definitions of the property.

So the full answer, as of PROF's current ED, to "What does prof:profileOf entail?" is that it entails transitive conformance, as per dct:conformsTo. No other claims are yet made.

I think there is a good case to make prof:isProfileOf a super property of owl:imports and perhaps some of the properties in VOAF but the document, as it stands, doesn't go there yet.

[nicholascar]

Closing as this question is answered to a point as per the NOTE publication.