Does "profile of" require all or some elements?

[kcoyle]

From the Shex community: It is also unclear to us whether it is helpful to describe the relation of a profile to its underlying namespaces in terms of a relation of Profile to Standard. The standard-to-profile relation is characterized as one of general-to-specific, but when namespaces simply provide just a handful of their terms to a profile, it seems like a stretch to say that the profile is "profiling" each of the namespaces. https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Feb/0001.html

[kcoyle]

From the profgui meeting of Feb 28:

2. "profile of" What conditions entail that one thing is a profile of another thing? a. - any use of elements (classes, properties), even if minimal (e.g. just use one DC term)[4 - Tom Bakers response] b. - use of all of the elements from a "base specification" and possibly add elements from another another specification and/or other constraints. c. - use of a "significant portion" of a base specification or other profile. d. - something is a profile of something else if the creator of the profile declares it as such

Note that if there is to be any formal inheritance then some of these definitions would not be usable.

Related issues: https://github.com/w3c/dxwg/issues/486

https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Mar/0014.html

[kcoyle]

response from Lars:

a. is definitely too weak, d. feels a bit arbitrary. I tend to b. rather than c. even though I understand that there are corner cases where this can be hard. (When it comes to machine-processability I tend towards relatively strict definitions...).

https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Mar/0079.html

[kcoyle]

Response from Makx:

I agree with Lars that b. makes the most sense. For example, the European DCAT-AP mentions each and every property in DCAT-2014 with a usage note. A profile could state "don't use property x" but it should say something about all terms from the specification it is a profile of.

Makx

https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Mar/0080.html

[smrgeoinfo]

I like the approach that 1) a profile is a specification that restricts one or more other specifications in some way. 2) a specification consists of rules/conformance classes/constraints (choose your favorite terminology) that dictate how some particular data resource can be validated as conforming to the specification. 3) A specification is an abstract concept. It is essentially like an FRBR work; there are various manifestations/expressions (maybe @kcoyle can clarify) of the specification as executable rules (shacl, shex, xsd, schematron.......). It's debatable whether these are 'representations' of the specification, or 'related resources'; either approach can work, choose one and be consistent. 4) Data resources that conform to a profile will also validate according to the rules of all base specification for that profile.
5) A profile may use elements from other specifications without inheriting all constraints from those specifications. These are not 'base specifications', they are 'related specifications' (or choose some other relationship terminology that you like). The profile must express any relevant rules for the use of these sort of elements, but that usage must be consistent with constraints from the source specification.

NOTE: edited 2019-03-11 based on subsequent comments by @kcoyle (constraints from related specs) and @makxdekkers (change 'artifact' to 'data resource')

[rob-metalinkage]

@smrgeoinfo .. that is correct and well put.

I think that this might be worth adding into a section on conformance vs reuse.

Only tweak is to make sure people dont confuse artifacts in section 4 with the artifacts used to describe a profile itself.

[makxdekkers]

It is better not to use words that have no clear meaning. 'Artifact' is such a word, basically a synonym for 'Thing'. It is much better to use a less ambiguous word. In the case of @smrgeoinfo's 'particular artifact' in point 2, something like 'data resource' (see my suggestion at https://github.com/w3c/dxwg/issues/572#issuecomment-439384612) or 'instance of a dataset description' could be used.

[kcoyle]

@smrgeoinfo 's #5 seems to be a new concept. Up until now I believe that all use of elements (properties and/or classes) from other vocabularies or profiles implied conformance.

5. "A profile may use elements from other specifications without inheriting conformance constraints from those specifications."

Also, when engaging in inheritance, how would you know which elements do not need to conform?

[smrgeoinfo]

@makxdekkers thanks for that refinement. @kcoyle the rest of 5 "The profile must express any relevant rules for the use of these sort of elements." is intended to answer that, but it need further thought. I would assume that any domain and range constraints from the original element definition would need to be honored, if they exist.

[kcoyle]

Thanks, @smrgeoinfo. I'm still not sure which (if any) of the definitions on the extent of "profile of" your definition selects. The big question is whether "profile of" implies using an entire specification or something else. The ShEx community response from Tom Baker debated that any profile using a handful of, say, Dublin Core properties mixed in with other namespaces can be said to be a "profile of" Dublin Core. By that definition just about every vocabulary in the Linked Open Vocabularies is a profile of Dublin Core, as is DCAT. So can you say if any of the a.-d. definitions meet yours? Thanks.

[rob-metalinkage]

Were are not talking about reuse or properties, only constraints that have conformance implications. Axioms of the base specification must be respected but option elements remain optional elements unless your profile adds constraints. AFAICT there is no concept "conforms to the whole specification" independent of "is consistent with all constraints". (formal xxioms are a special type of constraint)

[kcoyle]

Rob, the question is different. I think you are responding to @smrgeoinfo 's #5, but above you seemed to agree with it. The question here is which of the options (a-d) laid out by the group do you see as being the meaning of "profile of"? We're trying to get consensus on this.

[smrgeoinfo]

The problem I see is that meaning of 'use of' (in a-c above) is not clear enough to be testable. My interest is to assist client software to select representations of resources from various distributions documented in catalog records. I'm imagining that the metadata record will be able to declare that a distribution conformsTo some profile X, and this statement will be used by client applications to select a distribution that they can work with, the implication being that the representation offered meets certain requirements in terms of vocabularies used, required elements, syntax etc.

[kcoyle]

@smrgeoinfo I agree that "use of" isn't clear. So if my profile states that it conforms to profileX, what do you expect that to mean in terms of actionability? What actions would you take? I think the trick is in your "meets certain requirements... etc." and we're trying to determine if there are requirements implied by profileOf. If there aren't then it isn't going to be actionable; if there are then it may not satisfy all of the needs that folks have. Can we dig down into those "certain requirements"?

[smrgeoinfo]

Yes, the 'meets certain requirements' bit is the catch. Going back to the 1-5 points in a previous comment, those requirements would have to be asserted in the specification for the profile and any base specifications for that profile. If there are no requirements asserted by those specifications, then there isn't anything to conform to, in which case 'profileOf' has no testable implications. In that case, I suppose in rdf thinking 'profileOf' would mean 'uses some vocabulary (or elements?) from...' or something like that?

[kcoyle]

That's the whole question here - PROF doesn't provide anything beyond "profileOf", and it has to have a definition. Defining it as "profileOf means X is a profile of Y" doesn't say anything. That's kind of like the Mr. Ed theme song: a horse is a horse of course. We're trying to get consensus on a meaning of profileOf when used in PROF. You seem comfortable with "uses some vocabulary" which seems to be choice a. Lars and Makx have opted for b. Point b is pretty restrictive, but it is testable, which a, c, and d are not. You can compare your profile with Y and have a yes/no answer.

[rob-metalinkage]

A specification with no "conformance requirements" is a strange concept - even something like Dublin core has range declarations which are a constraint. If you narrow these, or narrow cardinality (i.e. make author mandatory) then profileOf is appropriate. These cases are all clear with the concept of constraints.

I think the "uses some vocabulary" phrase might actually be code for a more specific concept about "recommended usage where constraints are not testable". As far as I am concerned Profiles is silent about these - unless a community wants to elevate recommendations to a constraint: I can imagine a spec X (or community profile of it!) stating that more specialised profiles must "use the recommendations from X or provide an explicitly modelled alternative which a usage note stating why the recommendation wasnt considered appropriate". IMHO such a requirement is a constraint, and elevates recommendations to a constraint in this context. (this is partly why we removed Base Specification as a class - its more about the role something plays than something intrinsic to a specification.

Not all constraints are expressible formally - but Profiles is quite happy for you to have a guidance note only. At this stage there is no substantive change required, but some better guidance around scope not including general re-use has been indicated.

Definitions are already being addressed via a review #755 so the self-referential documentation style is being addressed elsewhere and this is no the place to reintroduce it. We must keep issues separate and linked if we are to make progress and avoid circular arguments.

[kcoyle]

@rob-metalinkage We still need to know what "profileOf" means. Only then can we address how to write the defintion.

[rob-metalinkage]

the object of a profileOf defines a set of constraints that must be met by resources conforming to the subject of the predicate, in addition to constraints directly defined by the subject profile.

[kcoyle]

@rob-metalinkage What predicate? This is the first time it has been defined on the predicat, although that is logical. Is a profile a set of predicates? That would make this more clear. Can a profile be more than predicates?

Here's where I think the confusion comes in. "Profile" itself is being defined very broadly as a set of documents, some of which don't even have predicates. In fact, they may not be in RDF or in any other machine-actionable code. If profileOf is limited to machine-actionable schemas, then the definition of it needs to include that, and it needs to be clear that this is a different meaning of profile. If it is limited to schemas in RDF, then it needs to say that. Using the definition we have used for "profile", profileOf (adding "Of" to our defined "profile") can't mean anything related to processing of constraints. If it does mean conforming to constraints, then it has to be clear that it can only be used on resources that define constraints.

The problem that I see is that "profile" so broadly defined that basing any processing on "profile" is not meaningful. Other than discovery of resources, I don't think that "profile" is machine-actionable as it is defined. Actionability could be defined on certain resources but that would require having a defined set of resources that are actionable. I think that's at least a v. 1.1 use case, if not 2.0.

[rob-metalinkage]

OK - the concept is so simple its hard to see why there is any debate, except for perhaps people trying to characterise generic re-use in OWA as some sort of profiling (it isnt).

So here it is in code, maybe that will help:

: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)

also note (because it seems to also be misunderstood or queried often enough):

:Profile1 a dct:Standard . (from dct:conformsTo range definition) :Profile2 a dct:Standard (from isProfileOf range definition)

I will add this as a proposal to a new issue (#844 ) so it can be dealt with properly independently of the original question.

So the answer to the original question is "no", if you mean elements defined in the context of "underlying namespaces" but "yes" if you mean constraints on elements referenced indirectly through isProfileOf. So, it would be a stretch to characterise re-use as profiling but as that's not what we are saying we should close this issue.

Improved definitions and examples should address the issue.

Please vote to close this.

[agreiner]

What happens when :aResource dct:conformsTo :Profile1 . :Profile1 prof:isProfileOf :Profile2 . :Profile1 prof:isProfileOf :Profile3 . and Profile2 and Profile3 disagree on one or more terms used in Profile1? In that case, I don't think that :aResource dct:conformsTo :Profile1 implies that aResource dct:conformsTo :Profile2

[rob-metalinkage]

If Profiles 2 and 3 are inconsistent then the statements are simply inconsistent - this is not a problem with the ontology - its a problem with the example. The implication is necessary because without it it is an essentially meaningless relation - and you could just use dct:relation or some other thing like skos:closeMatch. We are not modelling "closeness" in any way - only conformance inferences.

[agreiner]

That would only be true if one cannot borrow terms from more than one source that do not agree on all terms used. But the whole point of using a second source would be to use terms that differ from the first one.

[nicholascar]

@agreiner What you're asking for can't be solved by a vocabulary.

If Profile1 requires a particular property and Profile2 requires another, data could possibly be conformant with both, if they are not exclusive. If either Profile1 or Profile2 were exclusive, then something in the real-world couldn't conform to both of them. PROF's not getting in the way here but neither can it assist the users to overcome real-world conformances.

[kcoyle]

While a vocabulary alone cannot solve these issues, I think the question is whether the community around the vocabulary shouldn't have a solution. In most vocabularies that I know there are things that the vocabulary alone cannot impose, but the intention of the community is clear. Naturally anyone can create bad data, but the intention of the vocabulary, and the reasons behind that, are known. Then a standard constraint application or language can be applied. I would interpret Annette's question as one to the community: what do you mean by this? what rules do you expect users to adhere to?

[agreiner]

Let's take a more concrete example. Suppose you've been using DCAT 1.0 for a long time and now want to include APIs in your catalog. You make a profile of DCAT that also pulls in API descriptors from Schema.org's Data Catalog, so it's a profile of both DCAT and Schema.org. You cannot then assume that any dataset that is conformant to your profile is also conformant to schema.org.

[nicholascar]

@agreiner you're doing this backwards! If you're the system designer and the one creating the profile, it's up to you to tell others what to expect. So if you said that your catalogue is using something that is a profile of DCAT and Schema.org then you are saying users can expect it to be conformant to both. If you have something that presents as a schema:Dataset then it should follow Schema.org's rules about datasets.

Since Schema.org has pretty loose domains and ranges, I guess you could use it without committing your dcat:Datasets to be schema:datasets but if you are using properties that do entail such classing, you should use the classes legally.

@kcoyle I agree that community rules around what profiling means should be present - this is the Guidance document right?

[agreiner]

@nicholascar , you are assuming that a profile cannot be derived from more than one source unless the sources are conformant with each other in every respect. I think that limits the usefulness of profiles more than we want.

[kcoyle]

Nick, the guidance document is a general document about profiles so it won't give details about PROF. If the PROF vocabulary is going to be useful it probably needs a guidance document or user guide of its own to explain better to people what everything means. Sometimes people do this in a primer.

I agree with @agreiner that conformance to profiles and vocabularies used is tricky and possibly not realistic. It has seemed to me always that conformance to terms works but conformance to entire profiles is much more difficult.

[rob-metalinkage]

wow... there has never been any suggestion that some concept of partial conformance to a specification was a meaningful concept. you can't be conformant to a term - you may conform to constraints related to a term - but if you violate some of these you are not conformant to the specification.

All the Use Cases proposed assume conformance is an absolute concept since they do not define any form of partial conformance.

If you wish to propose a new set of requirements then you need to provide and get a new motivating Use Case agreed.

[dr-shorthair]

Hmm. I tend to agree with Rob here: a profile will usually define a whole set of required structures and permitted values. Conformance to the whole profile is the goal. If any part of it is 'optional' then that can be omitted, but otherwise, this would be a yes-no operation over the whole thing.

[nicholascar]

@agreiner yes, within the limits @dr-shorthair mentions.

@kcoyle

If the PROF vocabulary is going to be useful it probably needs a guidance document or user guide of its own

Something to think about post June perhaps... We already have a solid foundation of a lot of examples to work with, though they may all need updating still as we complete PROF.

In line with the plenary directive, I'm not going to monitor this Issue for the pause time period now.

[kcoyle]

@dr-shorthair So you would opt for "b" as a definition of profileOf, right?

@rob-metalinkage Dublin Core profiles have no "profile of" concept, only adherence to defined terms and the definitions and constraints that define those terms in their "original" vocabulary declaration. Yet, they are profiles. We'll be initiating some more work on the DC profile concept; I'll keep in mind whether any concept of "profile of" makes sense in that environment.

[smrgeoinfo]

Basic issue-- communicate to a client application what rules they can assume will be followed in an instance document representing some resource; this allows a developer to write software to access information contained in the representation. Assumptions:

1. there is some specification (spec1) that elucidates the rules followed by a given resource representation.
2. specification (spec1) can use rules from other specifications (specX). a. If all rules from specX are part of spec1, but some rules are restricted in some way consistent with specX, then spec1 is PROFILEOF specX. b. If all specX rules are followed but not modified, then spec1 INHERITSFROM specX. c. if Spec1 only uses some rules from specX (consistent with specX), then spec1 USES specX, and Spec1 must be clear about what it is using from specX and how.

If either spec1 or specX does not specify any conformance rules for representations, then the whole discussion is moot.

[agreiner]

Yes, I've been thinking along those lines, especially 2a and 2c. I'm fine with restricting profileOf to the case where any dataset that conforms to spec1 also conforms to specX, as long we also enable bringing in terms from other sources in addition. "Uses" is as good a term as any. I think one could use large sections of other profiles or standards, even using more terms from any one of them than from the one it is a profileOf. This would work if the terms brought in don't conflict with the spec that the profile is a profileOf. It should not be problematic for terms in a "used" spec that are not used in the profile to conflict with the "profiled" spec. This is analogous to reusing terms from one vocabulary in another, where that usage does not entail conformance with the entire original vocabulary. One could not infer that a dataset that conforms to a profile also conforms to a specification that the profile uses, but one could infer that a dataset that conforms to a profile also conforms to a specification that the profile is a profileOf. @rob-metalinkage, I'm being careful here to discuss conformance of datasets to specifications and profiles, not conformance of profiles to profiles. The relationships between profiles are not about conformance. We are defining something new here.

[rob-metalinkage]

@smrgeoinfo correctly distinguishes different dependency cases. the Profiles Vocabulary currently only addresses 2a, which is the case where we have explicit motivating Use Cases.

2b is addressed by owl:imports IMHO, and doesnt require a new vocabulary, though it does require an OWL/RDFS implementation. We could define this new UC and a new property.

2c is AFAICT addressed by re-use without an owl:imports, but there is no canonical way of getting the model for a specific term. This is a rather tricky general RDFS problem that I think is not possible to address in this scope IMHO. So maybe a new type of dependency could be defined for "uses terms from", and profileOf is a subproperty of this property. not sure this really logically fits inside a Profile scope, and if we include that is there any other support for this UC we could usefully provide? (without UC and examples its hard to guess)

If people really need to address the other cases happy to consider new UC and extensions.

[rob-metalinkage]

This is a rambling discussion as people try to understand - but there is not substantive issue here to address. The actual issue is being addressed at #844 where it looks like it is worthwhile introducing a formalism to prevent all sorts of interpretations being argued without any functional value evidenced for those other cases which could be handled by other vocabularies if required and actually definable.

This issue should be closed - iuts done its job to allow discussion to be collated - its archived status preserves the discussion and it doesnt have an actionable resolution.

[rob-metalinkage]

The question in the issue is actually one about how communities define conformance - and this doesnt need to be addressed in prof beyond the improvement in wording - this has been discussed at length in multiple issues - but a clarification needs to be inserted into the text.

[nicholascar]

The following sentence is now present in the ED's Introduction, immediately after the isProfileOf / conformsTo axiom:

Individual communities may define what conformance to their profiles and the things they profile means and how to test for conformance if indeed they wish to.

[rob-metalinkage]

This should be closed now as any further discussion should be raised with a specific proposal or evidence of an issue in dx-prof project repo. No discussion about semantics of conformance is relevant there, since usage of a PROF described specification as range of dcterms:conformsTo merely applies the same semantics as dcterms:conformsTo - which is up to the community to determine.

[andrea-perego]

Thanks, @rob-metalinkage . So, the question is whether this is or not in scope with the Profile Guidance document.

[kcoyle]

I do not recall the profile guidance document having considered this "profile of" relationship, although it would be good to think about the concept in general. My feeling is that the guidance document will state that "profile of" is not a precise or useful designation in most cases. However, I think this needs to be transferred to the PROF github area since this was specifically a response to the prof:profileOf property and the issues listed here have not been resolved in the text. I also think that the discussion here has been quite detailed/specific but that no resolution was ever arrived at.

[rob-metalinkage]

Already addressed in PROF - it merely used assumes same semantics as dcterms:conformsTo - which is however a community chooses to interpret conformance, PROF allows description of what is being conformed to, not how.

[kcoyle]

I find this area of the document quite confusing, tbh. The vocabulary includes dct:conformsTo as well as prof:isProfileOf. The latter has a range of dct:Standard. I don't see how the prof property has any relation to the dct property, other than a note. The statement under the former is unclear:

Note that the axiom within this vocabulary that allows the inference that conformance to a profile means conformance to anything it profiles (as per dct:conformsTo)

If prof:profileOf has the same semantics as dct:conformsTo then it isn't clear why both properties are needed. Perhaps that needs to be made clearer.

In addition, I think it would be good to solicit agreement from the folks in this discussion to see if this solves their questions.

[nicholascar]

I don't see how the prof property has any relation to the dct property, other than a note.

You have indicated the note in the prof:isProfileOf property definition that points to the dct:conformsTo usage notes that give the formal, ontological axiom: https://www.w3.org/TR/dx-prof/#Property:conformsTo, viz:

Property Chain Axiom: owl:propertyChainAxiom ( prof:isProfileOf dct:conformsTo )

This is precisely the mechanism used to formally relate the prof and dct properties

[kcoyle]

@nicholascar Ah, I missed that, thanks - I was focused on the prof:isProfileOf definition, which doesn't include that. However, I still don't see that they have the "same semantics". In fact, their definitions differ considerably - which is fine. I also vaguely understand that the property chain needs an "anchor" such as a super (or super-super) class. Anyway, I guess my response is "whatever". The proof will be in the pudding, as it were.

[rob-metalinkage]

They dont have the same semantics at all. The axiom makes the inference chain explicit, and does not state these are equivalent. People dont like axiomitisation because its hard to read, and I get that, but it also makes things explicit and unambiguous so we reluctantly included it because this inferencing is the point here.