W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > March 2010

Re: Proposal for ISSUE-11: Default prefix declarations

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Wed, 3 Mar 2010 17:46:32 +0000
Message-ID: <640dd5061003030946o2741e8b6o1fa8be05cc280bb@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: RDFa WG <public-rdfa-wg@w3.org>
Hi Manu,

The more I think about it, the more I don't like this idea...sorry. :)

However, sticking with the discussion in its own terms for now, can I
suggest that we discuss this as a default profile, rather than a
default set of URI mappings? (I realise that this somewhat depends on
the @profile proposal, but I think that's reasonable, at least whilst
we're still in the design phase.)

The effect of coming at it like this would be to breaking the default
URI mapping question into two parts:

The first would be that we create a profile that contains the token
mappings that you are talking about, such as DC, FOAF, and so on --
call it 'profile X'. As you point out, the exact list will be the
subject of much discussion. :)

The second step would be to specify that "the default profile for RDFa
1.1 is 'profile X'".

At the very least this will make it easier to discuss this issue,
since we will then have a name for this collection of URI mappings --
a profile.

It would also make it easier to manage, since in the future we might
simply say that the default profile is now 'profile Y', and instead of
listing all of the mappings that have changed (this version of DC,
that version of FOAF, the addition of SIOC, etc.), we'd simply refer
to the new profile.

This management question may be important; by putting all defaults
into a profile it's also easier to switch them off in one go if we
want to, because all you have to do is to define a mechanism for
either turning off the default profile, or replacing it with another.

For example, if some host language wants to define a different set of
mappings and remove ours, it would be very difficult to do so with the
current proposal. However, if the host language authors were to simply
say that the default profile for their language is 'profile Z', then
the job is done -- they get their default mappings, and lose ours.

Also, what if someone invents a URI scheme of 'dc'? In the current
proposal there is no way to turn that off -- we can override it, and
use a different URI for the token, but we can't turn it off so that it
can be used in a URI. (Well, you could add @xmlns:dc="dc" to turn it
off, but it's a little flakey.)

Well, if we deal in profiles rather than URI mappings, we could say
that the default profile is only used if no @profile value is set.

I'll end by saying that this last point is why I don't like the idea
of default mappings -- they essentially convert genuine URIs into
CURIEs, regardless of the authors intentions, and I think we're
storing up trouble. I also think it's rarely going to be necessary
anyway, because my guess is that people will probably use @profile
properly, since it will save them having to enter so many token

(I think the key to getting people to use @profile properly will be to
have profiles that contain lots of terms, rather than the author
having to list many profile URIs. That way it will become part of
their boiler-plate code.)



On Mon, Mar 1, 2010 at 3:51 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> One of the criticisms of RDFa 1.0 is that certain snippets may fail
> under cut and paste scenarios. This criticism comes from two directions:
> 1. It has been asserted that the xmlns: syntax for prefix declaration
>   is confusing and that authors may not use it correctly.
> 2. It has been asserted that authors may haphazardly copy-and-paste
>   popular RDFa markup such as SIOC, FOAF or Dublin Core terms.
> So, for example, an author may take this:
> <div xmlns:dc="http://purl.org/dc/elements/1.1/">
>   ...
>   <div about="/alice/posts/trouble_with_bob">
>      <h2 property="dc:title">The trouble with Bob</h2>
>      <h3 property="dc:creator">Alice</h3>
>      ...
>   </div>
> and copy-and-paste just this part into their document:
>   <div about="/alice/posts/trouble_with_bob">
>      <h2 property="dc:title">The trouble with Bob</h2>
>      <h3 property="dc:creator">Alice</h3>
>      ...
>   </div>
> This copy-paste error in RDFa 1.0 would result in no triples being
> generated because the "dc:" prefix is undefined. The author forgot to
> copy the xmlns:dc="..." declaration.
> We could address the most common markup errors by defining a list of
> default URI mappings, for example:
> """
> The list of default URI mappings is:
>   rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns#
>   rdfs: http://www.w3.org/2000/01/rdf-schema#
>   dc: http://purl.org/dc/terms/
>   foaf: http://xmlns.com/foaf/0.1/
> """
> We would then modify the initialization of the RDFa Processor in Section
> 5.5: Sequence[1] from this:
> """
>   the list of URI mappings is empty;
> """
> to this:
> """
>   this list of URI mappings is set to the list of default URI mappings;
> """
> The default list of URI mappings can be overwritten during operation of
> the processing rules. So, if the author re-defines the "dc" prefix in
> the current context to another value, the new value would be used to
> generate triples in the current context.
> Note that this proposal does not attempt to determine the ideal list of
> default URI mappings. That would be best accomplished by using the "top
> N list of most commonly requested vocabularies" on prefix.cc[2], getting
> prefix usage data from Google or Yahoo, or using another data-driven
> approach that can be done at a later time. Preferably, we would wait
> until just before Last Call to finalize the list of default URI mappings.
> Also note that another benefit of this proposal is that the author will
> not need to declare prefix mappings using xmlns: for the most commonly
> used RDFa prefixes.
> -- manu
> [1] http://htmlwg.mn.aptest.com/rdfawg/rdfa-core/#sequence
> [2] http://prefix.cc/
> --
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: PaySwarming Goes Open Source
> http://blog.digitalbazaar.com/2010/02/01/bitmunk-payswarming/
Received on Wednesday, 3 March 2010 17:47:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:46 UTC