Re: ISSUE-143 (Prefixes too complicated): Use of prefixes is too complicated for a Web technology [RDFa 1.1 in HTML5]

...

>> 1. Discover and document the common prefixes in use, define them to
>> always be bound to the URL they're commonly bound to, even without
>> an actual declaration, and don't allow them to be bound to a URL
>> other than that predefined one.

I agree with Manu's comments below. I particularly think it's unwise
to not allow local overriding of prefix bindings. I will be happy to
provide local bindings for all the prefixes I use in the expectation
that doing so adds to the ongoing robustness of the RDFa I publish.

 But again, why do this at all? The existing 1.1 prefix mechanism
works well, is optional, and tractable from both an author and parser
perspective. Additionally, the arguments to change it are either not
compelling, or unsupported or both.

 -Sebastian

>
> What is implicit in your proposal above is that we'd continue to support
> decentralized extensibility, but only for prefixes that are not
> pre-defined? If that's the case, what happens when a developer uses
> 'foo' today, but then the W3C decides to pre-define 'foo' in the future
> to map to a different URL? Wouldn't that break the author's document?
>
> That said, this is an interesting proposal, and one that I think we
> should implement *IF* there is data to back up the premise of the
> argument. The data should show that:
>
> 1) Declaring the same prefix to point to two different URLs is a
>    common practice on the Web, and
> 2) It leads to consumers mis-interpreting the data in a way that
>    generates the wrong data.
>
> I think #1 is true for the 'dc' prefix, but in that case, both
> 'elements' and 'terms' are largely compatible with one another. I can't
> think of any other vocabulary where this holds true. Seeing data showing
> that something like 'ogp' or 'schema' are being commonly mapped to two
> different vocabulary URLs would be very compelling evidence.
>
> We haven't seen any data to raise the concern that #2 is true. Do you
> have data demonstrating this assertion?
>

Received on Tuesday, 6 November 2012 22:18:20 UTC