refining the definition of profile in response to the poll

[pwin]

Following the poll there is a counter proposal;

The original presentation was:

Data Profile

A data specification that constrains, extends, combines, or provides guidance or explanation about the usage of other data specifications.

Data Specification

A specification, with human- and/or machine-processable representations, that defines the content and structure of data used in a given context.

============================================================= The counter proposal is for:

Data Profile

A data specification that constrains, extends, combines, or provides guidance or explanation about the usage other data specifications whereby the "given context" of the profile remains compliant with these "base" specifications.

Data Specification

A specification, with human- and/or machine-processable representations, that defines the content and structure of data used in a given context.

Please vote (up thumb vs down thumb) to give your view on the proposal, and discuss in the thread.

[larsgsvensson]

the "given context" or the profile

Should this be "the given context of the profile"?

[rob-metalinkage]

fixed

[tombaker]

@pwin I voted this down because it adds to the original proposal a note of prescriptive intent. The first half of the definition says what profiles are, and the second half (starting with "whereby") is actually a good-practice guideline, though I agree that a profile indeed should remain "compliant" with a base specification.

Also, it is unclear to me what the longer definition is saying. How can that context of a profile be compliant? What I think you are trying to say could perhaps be formulated as a usage note - outside of the definition per se. Something like:

A profile should be compliant with the data specifications
to which it refers.

[pwin]

Hmmmm, isn't the profile to be the data specification for a specific application? So isn't the data specification is (a significant part of) the profile? and that for a specific application the data needs to be compliant with the profile, rather than the other way round?

[tombaker]

@pwin Do you mean the following?

The data specification to which the profile refers should be compliant
with the profile.

[rob-metalinkage]

you would need a definition of compliant to make that work - which would state something like a profile P is compliant with a specification S if all objects compliant with the profile P are compliant with the specification S.

understanding what is the "conformanceTarget" is necessary - its "data in a given context" - not profiles themselves.

[rob-metalinkage]

Yes there is a prescriptive intent - it is vital that it is possible to identify what specification data conforms to - and if there is no prescription that data must conform to a specification when it is claimed to do so (e.g. the object of a dct:conformsTo predicate) then its all just random 1s and 0s in the ether in terms of information content.

[rob-metalinkage]

"given context" could be replaced by "data used in a given context" - its fairly obvious thats the only interpretation - but only if you read the data specification definition - so agree being more explicit would help there.

The rationale for the downvote is therefore not relevant as its based on a misunderstanding of this meaning- as per my comment above there is no statement, intent or requirement to talk about conformance of a profile itself, only about "data used in a given context".

[pwin]

https://uxdesign.cc/charles-eames-has-the-perfect-definition-of-design-5e47c61a6a6c

Q: “What is your definition of ‘Design,’ Monsieur Eames? A: “One could describe Design as a plan for arranging elements to accomplish a particular purpose.”

Isn't that the bare bones of 'profile' too?

[tombaker]

@pwin

arranging elements to accomplish a particular purpose

Indeed, my original proposal added:

A well-designed data profile provides
information, useful for describing data in a
given context, without semantically contradicting
the data specifications on which it is based.

[tombaker]

@rob-metalinkage I wonder if we are actually saying the same thing?

[andrea-perego]

@rob-metalinkage , I voted down for the counter-proposal since, IMO, it is adding unnecessary complexity, and in any case the wording is far from being straightforward or unambiguous. I don't catch exactly what the notion of "context" means here.

I suggest using as definition the original one proposed by @tombaker . Any additional statement with SHOULD / MAY can be included as an explanatory note.

[rob-metalinkage]

@tombaker - yes we are :-) - but having lost your original wording I'd like some form of it back ! I do think the wording needs to make it clear that "semantically consistent" applies to the "given context" - i can see how a specification that requires data not to be semantically consistent can be itself characterised as not "semantically consistent" - all i actually care about is that such a case cannot be declared to be a profile using our definition - as it then loses any implementation value as we cant make anything specific happen if anything can behave any way.

[rob-metalinkage]

@andrea-perego The "complexity" is already there - I'm trying to remove the complexity of having to look at the data specification definition to even find out what a profile is about... thats where "given context" is introduced and is therefore critical part of this definition whether stated or not in the definition of profile.

Find wording that solves that showstopper and I'll be happy.

[tombaker]

@rob-metalinkage My original wording said:

A well-designed data profile provides information useful for describing data in a
given context without semantically contradicting the data specifications on which it is based.

This goes beyond the scope of a definition (which should be about what something is) into that of a usage note (what something should be or how it should be done), so I presented it separately from the definition. Note that this positions a profile both with regard to "data in a given context" and to the specs on which it is based.

[I will be on break starting today so may be slow to respond.]

[kcoyle]

@tombaker 's "A well-designed data profile provides information useful for describing data in a given context without semantically contradicting the data specifications on which it is based." would be a great statement to make in the guidance document. Since this is a definition, not a prescription, I always ask the question: if this isn't true about this instance, does that make it "not a profile"? I think that there should be a difference between a sub-optimal profile and a non-profile. Profiles SHOULD NOT be inconsistent with any vocbulary terms they reuse, but if they do, they are still profiles, just not ones that we would recommend as being "the best".

[rob-metalinkage]

We dont have any UC for describing "non-profiles" and there is no propose metric for optimality - so profiles either meet the requirements of a profile or they dont. Introducing undefined concepts without evidence they are needs or useful doesnt move us forward.

There are two issues we need to satisfy ourselves on: 1) Does the notion of profile specify anything (and just saying its a type of specification says nothing), and if so what? 2) Does the definition unambiguously convey that notion.

At the moment the problem is not with the definition (other that it needs two definitions to convey any useful information about the behaviour of a profile). The problem is that we have and argument about the definition based on an interpretation that needs a lot more evidence to be acceptable:

i.e. there is no requirement for conformance to a profile to mean conformance to a profiled specification.

Can you actually cite evidence this interpretation makes any sense? what are the distinct behavioural characteristics that make "profile" not just a synonym for "specification".

Does some identifiable DC profile explicitly allow non-conformance with the semantics of DC? What wording does it use to specify this?

Can you cite any other profile that does not require conformance to a specification it claims to profile?

Can you suggest any meaning for the concept of profile if its just a specification, with no specific behavioural characteristics identified ? Could you actually model any such meaning?

I think perhaps there is a concept of "guidance notes" that have no conformance requirements that might match such a loose definition - and may have some value - but its not a sense that is relevant to Conneg-by-AP in particular or to the DCAT case (except as annotating some instance of dct:Standard) - so why would we even need to define it if each deliverable document would then need to define a more specific concept anyway?

[kcoyle]

I don't know what "undefined concepts" are present in that sentence of Tom's.

i.e. there is no requirement for conformance to a profile to mean conformance to a profiled specification.

1) What is a "profiled specification"? 2) "no requirement for conformance" begs the question of "what is conformance?" Again, what exactly does one test for? As an example, DCMI Metadata Terms do not include any rules about cardinality. If one creates a profile and adds cardinality, is that conformant? If there is a profile that gives the cardinaltiy of dct:title as 0..1, and another profile using that as a starting point gives the cardinality as 1..1, are these conformant? Really, if we can't say what has to conform we can't require conformance because it isn't meaningful to do so. And this also raises the question of whether conformance is a testable condition (e.g. you can write algorithms that return true or false in terms of conformance) or whether it is conceptual (without a possibility of testing other than human judgment). If it is the latter then we have a question that will not always return the same result, and may be circumstantial. In that case, insisting on conformance doesn't say much.

Can you cite any other profile that does not require conformance to a specification it claims to profile?

That depends greatly on the definition of conformance, which we don't seem to have. If we had one we could look at profiles and see if they meet our definition.

Can you suggest any meaning for the concept of profile if its just a specification, with no specific behavioural characteristics identified ?

Again, some unclear terms here. "just a specification"? What is "just a specification"? Since a profile IS A a type of specification then what does "just a specification" mean in this sense? And what are "behavioural characteristics"?

As if often the case, I wonder which statements refer to profiles and which refer to the instance data that the profile defines. In some of our discussions I feel like we are mixing those two, which may be some of the confusion.

[rob-metalinkage]

Quite obviously i have referenced the undefined concepts "non-profile" and "sub-optimal" you just introduced. Either you have not read the comment carefully or are misdirecting the conversation to avoid addressing the actual issues.

[rob-metalinkage]

Addressing the substantive issue you have re-raised - about the nature of conformance - i will reiterate the answer I suggest, in the absence of any other feedback on this topic: its up to specifications themselves to define what conformance means for those specifications. Many specifications have explicit conformance tests defined for example.

[rob-metalinkage]

And finally "As if often the case, I wonder which statements refer to profiles and which refer to the instance data that the profile defines. In some of our discussions I feel like we are mixing those two, which may be some of the confusion."

Yes i believe this is the case and I am continually pointing this out. Profiles (as with all data specifications) describe instance data - so profiling relates to subsets of instance data that conform to narrower but consistent definition of some profiled specification(s)

[kcoyle]

It seems to me that we have two "levels" of definition.

1. To define what a profile is
2. To define what is the relationship of instance data to the profile.

I think that Tom's definition covers 1. I also think that a profile doesn't itself do or implement anything. There needs to be some intermediary between the data definitions in the profile and the instance data that one hopes will conform to the profile. That requires a process of validation. The profile itself is not a process - I see it as a declaration. In the XML world, an XML schema defines the data (and one could create a profile in XSD), but until you run a validator (e.g. Schematron) you do not know whether the data conforms. With RDF one needs to run validation based on a SHACL or ShEx document.

My conclusion is that the profile defines but does not validate. Validation is a separate step, and therefore determination of conformance is not within the profile but its rules are defined by the profile. I find the wording in the XML documentation to be similar: "XML provides a mechanism to impose constraints on the storage layout and logical structure." XML does not constrain but provides the mechanism with which one can impose constraints. Then the document talks about "... describing the actions of an XML processor." So there is a processor that implements XML, the XML document is not that process.

I see the same difference between profiles and data validation against the profile. The latter is a process and I think that process is outside of our scope. In the DCMI profiles work, we are looking to align profiles with ShEx and perhaps SHACL so that those processors can validate conformance. But we accept that profiles are documents that inform validation of instance data but are not themselves a validation process. If you have a profile and some instance data, you still need something else to determine conformance. It's not the profile itself.

[rob-metalinkage]

Yes... note the model of profile in the PROF vocabulary which makes this distinction and the point i keep making that conformance is a matter for each community and platform to define and implement. We only need to define the relationship between specifications and data.

[larsgsvensson]

@kcoyle scripsit:

But we accept that profiles are documents

Nitpicking here: Didn't we agree on specifications instead of documents? From the Conneg point of view, the only important thing is the URI, so technically spoken the profile can be used (per its URI) even if it isn't documented anywhere (which of course is a very bad practice, but nonetheless...)

And yes, the profile is not a validation process. To say that :a dct:conformsTo :b and then dereference :b does not automatically validate :a against :b. @rob-metalinkage is spot on when he says that "conformance is a matter for each community and platform to define and implement".

[kcoyle]

RE: specifications v documents. Specification, as we've defined it, isn't a particular format/mime type. The issue I brought up is that we include those specifications that are not in a program-actionable form, such as Word documents or PDFs.

As for conformance, in Rob's question: "Can you cite any other profile that does not require conformance to a specification it claims to profile?" I agree that conformance is community-specific, and we should state it as such in any documentation. That means that "require conformance" is also community-specific so we can't make any definitive statements about whether a community requires conformance to a specification. It may require conformance to only part, it may not (yet) have conformance defined. However "We only need to define the relationship between specifications and data" seems to be something we cannot define because that relationship is what is community-specific; that relationship is the definition of "conformance".

[riccardoAlbertoni]

I voted against the counter-proposal, as I think it is less clear than the original definition. I would be in favor to add the tom's note, reported below, as an explanatory note after the original definition in order to convey @rob-metalinkage's remarks.

A well-designed data profile provides information useful for describing data in a given context without semantically contradicting the data specifications on which it is based.

[aisaac]

@riccardoAlbertoni I think this should be material for the Profile Guidance document indeed.

[aisaac]

@pwin @kcoyle is there any reason to keep this issue open? It seems that the main matter (the definition of profile) is handled and recorded in #963 . We could still keep this issue open in case some stuff could be added in Profile Guidance (the last comments hint that something can be done here). But that would be rather an editorial action - and with a shared understanding that I can close the issue when I judge everything has been incorporated.

[aisaac]

@riccardoAlbertoni I'm thinking of putting the note above in the "motivation" part of the Profile Guidance. It would look like the suggestion in section 2 in this working document. It's not right next to the definition, but it's really not far. Would it be ok?

[kcoyle]

I admit that I'm confused about the various issues about defining profiles. I'm not sure where this one stands, but I'm confident that the definition that Rob proposed during the poll has not been championed by anyone else in the group, and the definition in the poll was overwhelmingly (all positive votes except Rob's - sorry , Rob) voted positively. For that reason I would favor closing this as a way to finally put to rest the profile definition work.

[aisaac]

@kcoyle I would also want to close it, I think the definition stuff is handled. It's just that Riccardo wanted some bits of the discussion to be put in the Guidance, which I've just done. So one he says he's ok with the suggestion we can close.