W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > July 2011

Re: Eliminate @profile?

From: Stéphane Corlosquet <scorlosquet@gmail.com>
Date: Thu, 14 Jul 2011 14:58:39 -0400
Message-ID: <CAGR+nnGwmx7HbFJKKkuL7A+vZXK=mOPBCbrTRE8ZygWWz0ysSA@mail.gmail.com>
To: Gregg Kellogg <gregg@kellogg-assoc.com>
Cc: RDFa WG <public-rdfa-wg@w3.org>, "hsivonen@iki.fi" <hsivonen@iki.fi>
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
>
Received on Thursday, 14 July 2011 18:59:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:17 GMT