@profile

Nathan wrote:
> As yet I'm personally undecided as to whether the benefits outweigh the 
> potential problems

I've come to the conclusion that because additional resources need to be 
successfully dereferenced in order to successfully extract the *full* 
RDF graph serialized in an RDFa document which uses @profile, then:

@profile makes it possible for critical information (such as copyright 
licences, digital signatures, ownership information) to be effectively 
missing/ignored without the document owner/author having any knowledge 
or control over the situation.

Complexity in parsing together with both real and perceived latency is 
increased exponentially.

The number of additional resources that need to be dereferenced is 
unbounded (each of which inherits all @profile related issues)

Unlike a missing @prefix declaration which can be caught by validation 
tools, @prefix is impossible to validate (from a perspective that the 
graph produced by parsing an RDFa document containing @profile will 
temporally vary from that which was serialized in the document, without 
the author knowing or having any control).

Fundamentally it involves (or implies that) authors should treat 
prefixes as "more than sugar" which can lead to many decisions and 
notions such as:
  - treating a prefix as an identifier / short name for an ontology/schema.
  - the usage of, and reliance upon, default profiles, which may not be 
implemented in all RDFa parsing libraries.
  - competition for prefixes, implies that a "registry" is needed, which 
would entail registration, thus review, thus standardization - which 
ultimately would mean most people couldn't uses prefixes because the 
steps required to "own" a web scale prefix mapped to ontology would rule 
out most ontologies/schemas.
  - possible centralization, treating "profiles" as centralized 
registries for prefixes, the default profile being the primary one.
  - more.. (will leave it at that)

For me at least, the above *really* outweighs the benefits introduced by 
@profile, and sadly, I'd have to say that my personal opinion is that it 
should be removed from the specification - however as noted previously I 
value and respect the hard work you've all the decisions you've reached 
as a group.

This, with all due respect to the RDFa Core editors and the working 
group, I'd like to suggest that @profile is reviewed by some experts in 
the field before RDFa Core gets to recommendation, most likely Ned Freed 
and the IETF Types mailing list via <mailto:ietf-types@alvestrand.no>, 
somebody from the TAG and perhaps somebody from the HTTP working group.

Best,

Nathan

Received on Wednesday, 15 September 2010 23:32:41 UTC