-
Notifications
You must be signed in to change notification settings - Fork 55
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
Reviving work on the Profile Guidance document #1355
Comments
@andrea-perego I like the idea of thinking about it as more about practice and less about generalizations. My recollection about the lack of movement on that work item was that we didn't feel that we had the breadth of community to take on the work. In fact, the application profile community is extremely broad. This is why I feel that it isn't appropriate for work to take place within the DXWG about profiles in general, since this group is very strongly focused on DCAT. This group is unlikely to attract folks from other communities to work on profile guidance because they aren't watching the DXWG work. On the other hand, it might be very useful for the DCAT community to have a best practices document specific to DCAT-based profiles, since that is work that has already begun so people have experience to bring. I actually doubt if it is even possible to do a general AP guidance. In working on the recent Dublin Core specification for tabular profiles we found that it was hard even to define simple profiles for both RDF and non-RDF data with the same set of data elements, and we really are only representing a few metadata communities. Narrowing the scope to a specific community would probably mean a greater likelihood of success. |
The link to the DC work is somehow not displaying in the comment above, so it is: |
In defense of what @andrea-perego proposes, my recollection is that the formal aspects were indeed a hurdle - especially because inheritance always came back, while we could have progressed without it... |
It could be interesting to characterize how different communities see and use application profiles - whether "vocabularies" are seen as sharply distinct, whether profiles stand alone or may build on others, whether they depend on specific technologies or schema languages, whether they are subsets of just one standard or draw on several, what use cases are addressed, and the like. In other words, not one best practice, but a survey of current practices that draws out general issues of design. |
Just an idea....
My personal impression is that work on the Profile Guidance document was stuck because of lack of agreement in the definition of formal aspects on profiles and their relationships, consistently addressing all the contributed use cases and community practices. Should this be the case, I don't see an easy way out (of course, I might be wrong).
I wonder whether changing a bit the approach might help. E.g., what about turning the Profile Guidance document into a Best Practice document, distilling guidelines and recommendations from the use cases and community practices we are aware of? Wouldn't this be more effective for data providers?
Does this make any sense?
The text was updated successfully, but these errors were encountered: