Re: Eliminate @profile?

+1 for removing @profile.

Also even if no one mentioned it, I'm explicitly -1 on leaving @profile in a
hypothetic RDFa Full, and just removing it from a hypothetic RDFa Lite. I'm
against the whole idea of Full and Lite (again, we were not discussing this,
but the idea /might/ come up in the context of the @profile removal
discussion). Let's just make RDFa as a whole simple enough, and removing
@profile seems like a good step.

Thanks, Gregg, for the detailed write-up, as I could only follow on IRC
today.

Best,
Tom

Thank God not sent from a BlackBerry, but from my iPhone

On 14.07.2011, at 19:45, 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