-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use of "standard" #792
Comments
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 https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Feb/0001.html |
"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, |
@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. |
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. |
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 |
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 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." |
@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. |
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? |
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. |
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. |
@smrgeoinfo It does restrict the target to something that is a reference point for comparison. @kcoyle's suggestion to generalise it to |
@smrgeoinfo 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. |
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 See the latest version of the PROF document: |
@paulwalk are you happy/unhappy with the changes? |
@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
On this point, I agree with @kcoyle 's comment earlier in this thread:
|
@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. |
@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 :-) |
@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:
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 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? |
Addressing the ShEx community comments:
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.
All
In that case, it's likely a vocab supporting a profile/standard would be best described as a profile resource and formalised as a Is there any further work/explanation needed here? |
@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! |
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! |
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
The text was updated successfully, but these errors were encountered: