Re: Eliminate @profile?

On Jul 14, 2011, at 11:30 AM, Reece Dunn wrote:

On 14 July 2011 18:44, Gregg Kellogg <gregg@kellogg-assoc.com<mailto:gregg@kellogg-assoc.com>> wrote:
[snip]
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)?

>From RDFa Core 1.1 [1]:
The Host Language may require the automatic inclusion of one or more default RDFa Profiles. If it does, the RDFa Profile triples that establish term or URI mappings must not change without changing the associated profile URI. RDFa Processors may embed, cache, or retrieve the RDFa Profile triples associated with that profile.

For RDFa Core 1.1, this is http://w3.org/profile/rdfa-1.1 [2], For XHTML+RDFa 1.1 (and HTML+RDFa 1.1) this is http://w3.org/profile/html-rdfa-1.1 [3][4]

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.

That's what I do in my processor [5]. I have a routine for turning profiles into code accessed directly by the processor, and can easily update that.

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;

That's what the spec says, the URI must change if the contents changes [1].

 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?

This is true.

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/"?

Presumably, as the author, you are in control of what profiles you reference. And, if the profile owners play by the rules, the won't change.

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

Don't follow this; you should always be able to serialize the contents of an existing triple store correctly either by using full URIs, use of @vocab, and/or defining prefixes explicitly. Shouldn't really be necessary, because any use of a profile URI should remain stable.

- Reece


Gregg

[1] http://www.w3.org/TR/2011/WD-rdfa-core-20110331/#hostlangconf
[2] http://www.w3.org/TR/2011/WD-rdfa-core-20110331/#xmlrdfaconformance
[3] http://www.w3.org/TR/2011/WD-xhtml-rdfa-20110331/#additional-rdfa-processing-rules
[4] http://www.w3.org/TR/rdfa-in-html/#additional-rdfa-processing-rules
[5] https://github.com/gkellogg/rdf-rdfa/blob/master/lib/rdf/rdfa/profile/xhtml.rb