Re: @profile

Ivan Herman wrote:
> Nathan,
> 
> just editorial questions on what you wrote
> 
> On Sep 16, 2010, at 01:31 , Nathan wrote:
> 
>> 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
> 
> Do you mean @profile for the second time? Unless so, I cannot parse this sentence

yes @profile, sorry! I've rewritten everything from this point on to be 
(hopefully) clearer..

Fundamentally, @profile documents encourage RDFa authors to treat 
prefixes as "more than sugar". To explain:

Typically no weight is given to the string value of a prefix, the 
resolution of a prefix is on a per document level, where x: ns0: foaf: 
and foo: are all equally valid prefixes for use with any URI. That is to 
say the lexical form of the CURIE "x:name" has no more meaning, and 
serves as no more of an identifier, than the CURIE "foaf:name", they are 
not opaque identifiers, resolution of a CURIE happens on a per document 
level where the resolution of a specific prefix in one document does not 
infer the same resolution in another document.

@profile has a focus on the reuse of RDFa Profiles, which by inheritance 
places focus on reusing specific prefixes. This implies and promotes the 
usage of prefixes as universal identifiers / short names for an 
ontology. As if to say the lexical form of the CURIE "foaf:name" does 
have more meaning than the CURIE "x:name", that it serves as an opaque 
identifier, and that resolution of the prefix "foaf:" to a single fixed 
URI is expected universal behaviour. The notion of a "default profile" 
compounds this.

This fundamental change in how a prefix is viewed leads to unexpected 
behaviour in many scenarios, including but not limited to, when:
  - a default profile is not implemented in an RDFa parsing library
  - an author expects "default profile" behaviour in other 
serializations of RDF and where prefixes are used in other technologies 
(such as SPARQL)
  - a prefix (defined in an RDFa profile) is mapped to a different URI 
than the author expects

It also leads to undesired social behaviour such as competition for 
prefixes, implying that a "registry" is needed, which would entail 
registration, thus review, thus standardization of ontology+prefix 
pairs; 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. It also introduces 
possible centralization, treating CDN hosted profile documents as 
centralized registries for prefixes, the default profile being the 
primary registry (again introducing social competition where the goal is 
to get "my ontology + prefix" in to the "default profile").

.. end reword, hope that clarifies.

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 Thursday, 16 September 2010 10:21:29 UTC