Reference Data on the Web Best Practices

[nicholascar]

This issue was formerly a Note in the document

[kcoyle]

DBs? Was this about referring to the Data on the Web best practices for metadata? Or?

[aisaac]

@kcoyle @nicholascar I guess so!

[aisaac]

I'm changing the title myself. I am impatient to see it magically updated in the view for @nicholascar 's last PR :-)

[nicholascar]

I totally, totally, blame autocomplete for that one...

[kcoyle]

This is a very rough draft of a reading of DWBP in relation to profiles. I don't know if it fits into the document directly but using DWBP would fit this document into a W3C context. Obviously if we use this it would include links to those BPs.

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 [link] as a source of some preferred practices for profiles.

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.)

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).

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.)

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??).

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.)

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.

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).

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.

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.

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

[kcoyle]

Here is the respec guide on referencing best practices:

https://github.com/w3c/respec/wiki/ReSpec-Editor's-Guide#best-practice-documents

[aisaac]

Hi @kcoyle looking at the editorial work on sections 1-2 we may have to re-order the way that BPs are refered. Some general BPs relate to the core motivation for profile and thus may be introduced earlier in the doc than in section 2.7.
https://w3c.github.io/dxwg/profiles/#best-practices
NB: I don't think we should do it now. Let's just wait a bit until we stabilize the updates we're discussing.

[aisaac]

@kcoyle another comment for future updates: looking at
https://github.com/w3c/respec/wiki/ReSpec-Editor's-Guide#best-practice-documents
I'm wondering whether this is fit for our case, i.e. it looks like it's for documents that mint best practices, not documents that cite existing best practices. What do you think?

[kcoyle]

@aisaac Agree. I just popped them into the sections as placeholders. I'm sure we won't end up with them in those positions in the final document. Maybe they should be coded as notes? That's very close to the intention.

[kcoyle]

@aisaac I looked that the respec section on BP's but it says: "This feature is rarely used, and likely needs to be updated." That made me hesitate.

[aisaac]

@kcoyle thanks for the quick feedback! So when we work on the ticket again, we will change the formatting to something simpler. I'm fine with notes, or even simpler.