Re: Eliminate @profile?

On 14 July 2011 18:44, 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.

You'll need to CC the ePub 3.0 people as they are using @profile in
the document specification (they are essentially using a restricted
RDFa Core 1.1 syntax).

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

As an implementer who is processing/will process RDFa data I am
strongly in favour of being able to read RDF triples in an RDFa-based
document just using that document alone without any further
processing.

This means not having to do network resolutions to load RDFa profiles,
or running JavaScript on a document, to get any RDFa triples.

> Note that the default profile does not present the same problems, since it
> is assumed that RDFa processors will internally cache the default profile.

The default RDFa profile? I could not find a reference to this.

Or the default profile for a document type (e.g. the default profile
for ePub 3.0)?

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

Which will not be resolved using static processors such as rapper or
my library (I don't want to have to resolve one or more web URIs every
time a document is loaded). If I was to do the resolution, I would do
it as a one-time thing and keep the results indefinitely.

The problem here is how to update the profile data. The options are:
  1/  once published, a profile cannot define any new prefixes --
publish a different uri for a new version;
  2/  specify a timeout, or valid until in the profile to denote a
lifetime (i.e. when to reload the data, like is done with RSS)

>From an author point of view, I would find it problematic having the
prefixes separate from the document where they are used -- how do I
know whether dc: evaluates to the Dublin Core Terms or Elements uri if
I am using two different profiles for different documents?

What if I use someone's profile definitions (including ones I define)
and they decide to point a prefix elsewhere? E.g. changing foaf: from
"http://xmlns.com/foaf/0.1/" to "http://xmlns.com/foaf/spec/"?

How does this affect triple stores that have the triples saved for a document?

- Reece

Received on Thursday, 14 July 2011 18:31:32 UTC