Re: [dxwg] Profiles in relation to Data on the Web Best Practices

_Here's my first pass at reordering the best practices using the document outline. Again, this is not the text suggested for the document, this is an analysis of BPoW in relation to our work, without saying how we would use it._

Using the assumption that a profile on the web has some characteristics in common with data on the web, we can look to the [Data on the Web Best Practices](https://www.w3.org/TR/dwbp/) as a source of some preferred practices for profiles.

1. Introduction

BP13 Use locale-neutral data representations
Because profiles are intended to convey information both within a community and at times between communities, wide use would be facilitated by BP13, which is that the profile should use locale-neutral data representations where possible. Some data communities have deep and historical practices that use terminology that is specific to the community. The creation of a profile is an opportunity to transform that practice to widely known standards.

2. What is a profile?

BP15 Reuse vocabularies, preferably standardized ones
BP15 is one of the cornerstones of the profile practice, which is to reuse vocabularies, in particular standardized ones. One would need to define "standardized" in this context, but perhaps a better solution is to define the qualities of preferred vocabularies: have a stable URI; are supported by an organization or community; (more??). 

3. The Functions of Profile Components/Manifestations

BP16 Choose the right formalization level
The recommendation in BP16 is to choose the right formalization level. This is a useful recommendation for all data and metadata, and would naturally apply to profiles. Profiles should be suited to the tasks they are designed to support; not less nor more. In particular we should caution against overly strict use of constraints, which then make it harder for others to either make direct use of the profile or to create a profile of the profile where their needs vary only a small amount. 

4. Profile publication

BP9 Use persistent URIs as identifiers of datasets
The first obvious practice is BP9, to use persistent URIs as identifiers of profiles. This seems to be a non-controversial requirement because it applies to any web resource. There is a related best practice (BP10) which is stated as "Use persistent URIs as identifiers within datasets." This can be well-suited to the aspect of a profile that consists of the reuse of vocabulary terms that have been prevously defined, but also to the definition of new terms within the scope of the profile itself. Each element of a profile's vocabulary should have a URI (IRI?) that identifies the term and information about the term (such as labels, definitions, etc.) 

BP14 Provide data in multiple formats
The BPs also recommend that data be provided in multiple formats, and this is a good recommendation for profiles as well. If we take the point of view that profiles, like DCAT, have an abstract essence that can be made manifest in more than one way, we already have a good basis for satisfaction of BP14. (This will bring up the question that has already come up in the context of DCAT and conneg - are all of the forms equivalent? We may not be able to resolve that question.)

BP12 Use machine-readable standardized data formats 
Naturally, profiles should be published in standard data formats (BP12). It should also be stated that profiles should be published in and make use of technologies that are appropriate to the community which is expected to use them. A profile using RDF and OWL will not well serve a community that has only an XML/XSD-based skill set. This also relates to the above recommendation relating to providing data in multiple formats. In many communities the skills and data history can vary, so providing profiles with as many as possible of the commonly used technologies will increase the utility of the profile (as well as the profiled instance data).

5. Administrative and descriptive metadata

BP 1: Provide metadata
BP 2: Provide descriptive metadata
BP 3: Provide structural metadata 
The next relevant group of best practices have to do with describing the profile itself (BP1-3). In the BPoW this is defined as metadata about the dataset; with profiles this can be descriptive metadata within the profile or a separate metadata statement about the profile. (Since profiles themselves are generally forms of metadata they may be able to incorporate description and other administrative information about the profile within itself, if desired.) In addition there is a common set of administrative data that is recommended for many information resources such as dates and version designators for each version, and provenance (who or what agency created the digital file). 

BP2 Provide descriptive metadata
The BPDoW limits its recommendation of metadata covering the topic of the dataset to general keywords and themes and categories (BP2). It may be desirable provide more specific topical information to satisfy the DXWG requirement that profiles should be discoverable by search engines. The quality of discoverability will vary based on the depth of description of the topic and/or community area that it serves. (We may wish to recommend some particulars.)

BP30 Make feedback available
Ideally, the profile would have a management cycle for maintenance and updates. This should involve the community of users, as noted in BP29 (Gather feedback from data consumers) and BP30 (make feedback available). The strength and value of a profile will depend on the involvement of the community of users. 

BP27 Preserve identifiers
The aspect of the management cycle that is often ignored is that of the de-commissioning of datasets or of superseded versions. For users it is key that previously used identifiers always point to a useful document or message. (BP27 preserve identifiers). 

6. The Profiles ontology

BP 1: Provide metadata
BP 2: Provide descriptive metadata
BP 3: Provide structural metadata 
The next relevant group of best practices have to do with describing the profile itself (BP1-3). In the BPoW this is defined as metadata about the dataset; with profiles this can be descriptive metadata within the profile or a separate metadata statement about the profile. (Since profiles themselves are generally forms of metadata they may be able to incorporate description and other administrative information about the profile within itself, if desired.) In addition there is a common set of administrative data that is recommended for many information resources such as dates and version designators for each version, and provenance (who or what agency created the digital file). 

-- 
GitHub Notification of comment by kcoyle
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/487#issuecomment-435359960 using your GitHub account

Received on Friday, 2 November 2018 12:16:34 UTC