Eliminate @profile?

On today's  RDF Web Apps call [1], there was some discussion of @profile. ISSUE-96 [2] relates to document ready. I encourage people with an opinion on the use of @profile in RDFa to voice their opinions.

Basically, until all @profile documents are loaded and processed, an application cannot reliably access the RDFa API because the URI resolution of types and properties cannot be reliably resolved until all term and prefix definitions have complete. Also, the failure to load a profile can mean that an entire sub-tree of the document must be ignored.

Loading a profile is problematic due to HTTP same-origin restrictions [3]. This can be alleviated by insuring that profile documents are all CORS enabled, but it remains a complicating factor. Not all authors will be in a position to set CORS policy for served profiles.

A profile may fail to load because of network connectivity issues, meaning that the same document may be interpreted differently depending on environmental conditions.

Multiple profiles may define the same term differently, which could lead to confusion (on the part of the user, behavior is well-specified within the processing rules).

Note that the default profile does not present the same problems, since it is assumed that RDFa processors will internally cache the default profile. Concerns were raised about the relatively closed nature of relying on the default profile for prefix definitions, as frequent changes to the profile place a burden on processor developers, and even with a simple registration form, it places a barrier to entry and is generally not in the open nature of RDF.

Personally, I really see the advantage of a profile mechanism. In addition to declaring prefixes, it allows an author to establish a number of terms for use within their document. CURIEs have been criticized (rightly or wrongly) as being to complex and error prone, but terms are consistent with similar usage in Microdata and Microformats, but it's not feasible to include a large number of terms in a default profile, where term definitions may overlap between different vocabularies.

However, the use of profiles is a substantially complicating factor in RDFa. Removing it still makes RDFa authoring much simpler than other RDF variations, as for most developers, almost all of the prefix definitions they would need to use can be included in the default profile. Also, the use of @vocab provides much of the benefits of a custom profile when a single vocabulary is being used (e.g., http://www.w3.org/2006/03/hcard or http://schema.org/). Also, custom prefix definitions may still be introduced into a document using the @prefix definition.

This would also have the benefit that the RDFa API would not have profile load latency issues

* Potential same-origin problems in loading profile,
* Profile loading relies on network connectivity,
* Processing complication introduced due to profile load failure,
* Latency introduced by having to load profile before proceeding with application processing,
* Need to add notification mechanisms to know when profile processing has completed,
* Potential difference in CURIE/term meaning based on multiple overlapping profile definitions,
* No clear community requirement for profiles other than the default. (Sophisticated authors have other syntactic mechanisms to draw on).

At the time profiles were introduced, there was no mechanism for importing standard prefix definitions in bulk. For almost all cases, a built-in default profile definition addresses this issue. Going further to allow for arbitrary profile introduction may be going to far, at least for this particular version of the standard.

Gregg Kellogg

[1] http://www.w3.org/2010/02/rdfa/meetings/2011-07-14
[1] http://www.w3.org/2010/02/rdfa/track/issues/96
[2] http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0137.html

Received on Thursday, 14 July 2011 17:45:45 UTC