Re: Eliminate @profile?

As I said in the call, I'm +1 in favor of getting rid of @profile and the
associated complexity for implementors.

Steph.

On Thu, Jul 14, 2011 at 1:44 PM, Gregg Kellogg <gregg@kellogg-assoc.com>wrote:

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