Use of "standard"

[kcoyle]

From Paul Walk:

This describes a standard thus: "A Standard can be either a Base Specification (a Standard not profiling any other Standard) or a Profile (a Standard which does profile others)."

This is an interesting use of the word 'standard'. I appreciate that we have these imprecise terms, and that we have to arrange them somehow, and that this definition is not necessarily any worse than any other but, nonetheless, I find it a bit surprising. I have tended to view metadata application profiles as being an arrangement of properties and constraints, drawing from one or more namespaces (frequently from more than one namespace in the domains with which I am most familiar), in order to either facilitate some task, or to describe some domain. In this formulation, 'standard' is closer to 'namespace', and so I would expect a many-to-many relationship between standard and profile.

https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Jan/0006.html

[kcoyle]

This was also noted in the ShEx community comments:

"The relation of standard to profile also seems unclear in practice. Some people consider a specification to be a "standard" when published by a "standards" body such as ISO but not if published by, say, W3C or DCMI. And yet, because the domain of prof:hasProfile is dct:Standard, one could infer that any profile profiled by another profile is, ipso facto, also a standard. Should a vocabulary I just invented for this profile be considered a "standard" with respect to the profile? Given the diversity of opinions and perspectives on the distinction in natural language, we would expect diverse interpretations of its use in the Profile Ontology as well."

https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Feb/0001.html

[rob-metalinkage]

"one could infer that any profile profiled by another profile is, ipso facto, also a standard. " is indeed rational. what else could it be?

The description has been updated anyway to clarify, the comment supports the model proposed, so this issue could be closed. - its all essentially a duplicate of #802, #797 , #799 - these issues are all useful to make sure specific reviewers get targetted feedback but are all addressable by the same process of refining the descriptive text,

[kcoyle]

@rob-metalinkage I don't think this is the same as those comments. They are not totally unrelated, but each has its own meaning.

What you have here is someone who disagrees that all profiles are standards. Do you have a way to resolve this? Obviously this person DOES think it could be something else. You could ask for clarification as to why they do not think that subclassing profile to standard is a good idea.

[agreiner]

This question gets at the formality of profiles. I think they are less formal than a standard, without the same implication of vetting by some official group of people.

[smrgeoinfo]

This underscores the argument for talking about 'specifications' instead of 'standards'. The level of authority of a specification is really up to the user, what is important is that there is some public documentation that makes it clear what 'conforming to x' (whether x is a spec or standard) means.

the sentence in the first comment in this thread would then read "A specification can be either a Base Specification (not profiling any other specification) or a Profile (a specification that includes the provisions from some other specification (a base specification), with restrictions or additional logically consistent constraints)."

[rob-metalinkage]

remember we are subclassing dct:Standard and hence using its loose defitinition of standard - there is nothing about formal recognition of standards bodies etc.

One comment has suggested renaming Profile to be Specification. I do not favour this because it doesnt add anything to the definition of dct:Standard except a better name, and the Profiles Vocabulary is specifically scoped to address needs of profiling. There is nothing to stop use of resourceDescriptors and roles against a dct:Standard (or another equivalent Specification class).

I dont think we have collected all possible Use Cases for a general Specification ontology, but we know the Profile issues. We could rename Profile to Specification and the ontology to "Specifications and Profiles Vocabulary".

Pros: makes it explicit that the role-qualified resources can be used for any specification and addresses absence of a more general vocabulary Cons: potential arguments about claiming greater scope and lack of consultation with all possible specification writing communities

my view: better something agreed and useful than a future perfect all-encompassing scope

possible option:

add a new class Specification in the hierarchy (between dct:Standard and pro:Profile and axiomitise that a Profile has at least one isProfileOf relationship.

if the then rename to Specification and Profiles Vocabulary it then reflects that it at least refers to Specification from the perspective of profiling.

note that this makes no statement about formality of profiles or standards - it merely allows description of them. Other vocabularies could be used for that information if required.

My proposed response to Paul Walk would be "the term Standard derives from the usage in Dublin Core which does not proscribe any specific status, other than some community using it as a reference point." The association of namespaces with specifications (or "standards") is an artefact of encoding - and the Profiles vocabulary makes no assumptions about encoding or whether such a namespace is defined or unique. So the vocabulary supports the the "metadata profiles" use case you refer to, but applies to more general cases of specification expression."

[smrgeoinfo]

@rob-metalinkage, I like the language to get around baggage for 'standard' ("the term Standard derives from the usage in Dublin Core which does not proscribe any specific status, other than some community using it as a reference point.") +1.
I'd need to review the text, but perhaps instead of trying to add 'Specification' as a class, we could just define the term and use it in the document text when talking about a dct:Standard or a prof:Profile, since both are specifications?

[kcoyle]

Is there a need for a class at all? All properties default to being in the class rdf:Resource. What does adding dct:Standard gain us here?

[makxdekkers]

The reference to dct:Standard specifies the kind of things a profile applies to. It does not apply to things that are not specifications of entities, attributes and relationships, at least not as it is currently defined.

[smrgeoinfo]

doesn't seem that the dct:Standard definition ("A basis for comparison; a reference point against which other things can be evaluated.") actually restricts the standardization target for a dct:Standard in any way.

[makxdekkers]

@smrgeoinfo It does restrict the target to something that is a reference point for comparison. @kcoyle's suggestion to generalise it to rdfs:Resource would leave it completely open, and a profile could then apply to people, cars, ideas, the weather -- anything.

[kcoyle]

@smrgeoinfo +1 to @makxdekkers Remember that Paul Walk was objecting (mildly) to the definition of Standard in the text, not the use of dct:Standard.

But as others have said here, there will be folks who do not consider their all of their profiles to be "A basis for comparison; a reference point against which other things can be evaluated." In particular, I think that the "against which other things can be evaluated" is something that some folks will not associate with their profiles. Anyone can add an "rdf:type dct:Standard" to their RDF if they wish; it would be best not to bake this into PROF as it restricts the meaning of profile to that definition.

[nicholascar]

The way the words Standard & Specification are used in PROF have been altered greatly following WG discussions about definitions.

The specific sentence quoted at the top, "A Standard can be either a Base Specification (a Standard not profiling any other Standard) or a Profile (a Standard which does profile others).", is no longer present in the document.

The second issue "...I would expect a many-to-many relationship between standard and profile." is not excluded by PROF: one dct:Standard might have many prof:Profiles profiling it, a prof:Profile might profile many dct:Standards (or other profiles).

See the latest version of the PROF document: https://raw.githack.com/w3c/dxwg/prof-definitions/profilesont/index.html

[nicholascar]

@paulwalk are you happy/unhappy with the changes?

[paulwalk]

@nicholascar I have not re-read the PROF Document in full (cannot spare the time right now) but the changes you report above do seem to address my original comments.

The issue in this thread broadened slightly to cover the semantics of dct:standard (my original comment was not about the semantics of the DC Term). @rob-metalinkage said:

My proposed response to Paul Walk would be "the term Standard derives from the usage in Dublin Core which does not proscribe any specific status, other than some community using it as a reference point."

On this point, I agree with @kcoyle 's comment earlier in this thread:

...there will be folks who do not consider all of their profiles to be "A basis for comparison; a reference point against which other things can be evaluated." In particular, I think that the "against which other things can be evaluated" is something that some folks will not associate with their profiles.

[nicholascar]

@paulwalk thanks for the follow-up comments.

I understand the above points: in creating this vocabulary, we are hoping to move towards machine-readable things so we've used the notion of conformance to be central to a profile's definition: a profile conforms to things it profiles (specifications or other profiles) and things (instance data) may conform to profiles (or specifications). It may indeed be true that there are things out there known as profiles that do not expect or support such a notion of conformance.

I'm not sure what to say about that other than use of this vocabulary would probably not be sensible for such object.

[paulwalk]

@nicholascar thanks for the summary. However, I think we are misunderstanding each other...

I used the word 'validation' at the beginning of this thread, and I would define this in this context as the process by which conformance is evaluated.

I continue to think that validation is an important activity which I would like to see better supported by application profiles, and so it follows logically that I am interested (as you are) in ideas of conformance.

Where (I think) we differ is in the extent to which validation should or could be an entirely unmediated, completely automated process. I especially do not think that it is necessary, or probably even viable, to have a validation process which somehow works down through layers of "inherited" conformance rules.

My view of the potential power of application profiles is more akin to the "mashup" paradigm of a few years ago, when web services developers largely abandoned a set of formal and highly complex standards (known disparagingly at the time as "WS-*") in favour of reliance on simple standards and formats, and clear conventions in human-readable documentation. The big lesson from these years was that developer-mediated point-point integrations can work just fine, so long as the developer can discover quite easily what technologies and standards are being used to describe and deliver a given set of data or metadata.

Basically, I think that the whole business of inheritance, provenance chaining etc. should be put to one side, in favour of developing a good, understandable and efficient process for describing application profiles and then for validating datasets which are claimed to confirm to an application profile.

I hope I have managed to clarify. As I hope I remembered to say at the outset - this is an opinion rather than a DCMI sanctioned view, but I would point out that the extraordinary breadth of uptake of the DCMI Metadata Terms has in no small part been due to the scope constraints which the original developers set for themselves.

I hope this is useful, even if only a little :-)

[nicholascar]

@paulwalk I remember some of the "WS-*" issues, since I was, and ma, a web service developer!

I need to be able to draw this issue to a close - to resolve something, leave it unresolved, point to future work etc. Your final words here that suggest a course of action are:

Basically, I think that the whole business of inheritance, provenance chaining etc. should be put to one side, in favour of developing a good, understandable and efficient process for describing application profiles and then for validating datasets which are claimed to confirm to an application profile.

We, the PROF editors, do believe that PROF contains a "a good, understandable and efficient process for describing application profiles". It then also provides the hierarchy mechanism of indicating what things profiles which may or may not ever be used, time will tell! It's there if developers want it and, I guess, we'll only be able to see its utility when we have some real hierarchies present in data, but we can't make the hierarchies until we've formally characterised profiles (in PROF), hence the descriptive part of PROF...

Regarding "validating datasets which are claimed to confirm to an application profile": We've never felt that we can do much more here than identify profiles, which then provides conformance targets, and then link validating resources (SHACL etc.) to those identifiers in a formal way (via the ResourceDescriptor task with a role of 'validation' for instance). There are just too many ways in which communities might seek to validate datasetes. For example, ODRL2 has a detailed set of instructions about profiling ODRL2. That's for the community to define, we (PROF) just ensure that the ORDL standards & profiles are described using a "good, understandable and efficient process" which indeed the ODRL Community Group have agreed to do, see https://w3c.github.io/odrl/profile-bp/#profilevocab.

So, we think we are "developing a good, understandable and efficient process for describing application profiles" (suggestions welcome on better ways to do this!) and we include defer to individual communities for "validating datasets which are claimed to confirm to an application profile" but provide some generic mechanics around profile IDing & resource linking and we just wait and see regarding the utility of enabling hierarchies.

This may not perhaps be exactly the outcome you wished for but does it indicate we have understood your points and addressed them?

[nicholascar]

Addressing the ShEx community comments:

The relation of standard to profile also seems unclear in practice. Some people consider a specification to be a "standard" when published by a "standards" body such as ISO but not if published by, say, W3C or DCMI.

We have used the word 'specification' and/or throughout the document and have given a series of definitions within it too that were agreed on by the WG.

...because the domain of prof:hasProfile is dct:Standard, one could infer that any profile profiled by another profile is, ipso facto, also a standard.

All prof:Profile instances are dct:Standard given prof:Profile rdfs:subClassOf dct:Standard. The property linking profiles & standards, prof:isProfileOf, is now the only linking property with the inverse that you reference prof:hasProfile having been removed from the vocabulary.

Should a vocabulary I just invented for this profile be considered a "standard" with respect to the profile?

In that case, it's likely a vocab supporting a profile/standard would be best described as a profile resource and formalised as a ResourceDescriptor with a relevant role.

Is there any further work/explanation needed here?

[paulwalk]

@nicholascar thanks for the comment! I guess this has reached the point where we just have to agree to differ, so I won't press this further. I remain pessimistic about your chances of getting wide adoption - but that doesn't mean that I wouldn't be happy if you managed it!

[nicholascar]

Thanks @paulwalk. It is a tiny vocab after all so it it's only used to identify profiles and then other properties, like DCT, are used to describe them, great!