Re: RDFa Lite and non-RDFa @rel values [Final Take?]

Grant,

On Wed, Apr 25, 2012 at 10:58 PM, Grant Robertson <grantsr@gmail.com> wrote:
> Dan,
>
> That would require a complete rewrite of RDF 1.1 Core. The whole purpose of
> @property emulating @rel in special cases (what I call "Special Property
> Mode") is to allow similar behavior but without chaining. To strip @rel from
> RDFa would eliminate chaining. To restore that chaining, but without @rel,
> would require a major rethink in the algorithm.
>
> Personally, I think repurposing attributes - first @rel and now @property,
> is a big mistake. But, as Ivan said, the spec and the documentation process
> have come so far now that it can't be turned back without major possible
> repurcussions in the public's acceptance and implementation of the standard.

RDFa (since 1.0) attempted to rectify the lack of generalized
assignment of meaning to @rel values. But we see that using @vocab and
@rel together in HTML5, when knowing about e.g. 'nofollow', but
nothing or only Lite about RDFa, may cause problems. There are means
to either communicate this, or if special treatment of @rel in HTML is
deemed necessary, to address this wholly in HTML5+RDFa. There is no
need for any complete rewrite.

Also, @property wasn't repurposed, it was extended, due to empirical
evidence that people not knowing about @rel expected it to also
capture @href. RDFa fully controls the meaning of @property. This made
Lite easier, which is good. Using chaining with @rel is advanced RDFa.
Anything it captures can be expressed with just @property plus either
@href, @resource or @typeof, albeit it costs more due to repetition.

Best regards,
Niklas


> On Apr 25, 2012 1:32 PM, "Dan Brickley" <danbri@danbri.org> wrote:
>> Could someone clarify what the story looks like if all RDF-ish stuff
>> goes into @property, along lines of RDFa Lite? is the risk just that
>> of some 'junk' or poorly patterned triples driven from rel='me',
>> rel='nofollow' etc?
>>
>> Dan

Received on Wednesday, 25 April 2012 22:59:33 UTC