Re: ISSUE-76: If we fixed namespaces, does RDFa still have problems?

Personal opinion:

On Dec 10, 2009, at 4:26 PM, Ennals, Robert wrote:

> I’d like to draw attention to a point that Sam Ruby made a while  
> back, when we were discussing my proposal for decentralized  
> extensibility [ISSUE-41].
>
> It seems that one of the biggest things that people don’t like about  
> RDFa, and thus one of the biggest reasons for creating Microdata, is  
> that RDFa uses namespaces, and namespaces are really hard to use  
> because the meaning of prefixes varies. However, if we adopted my  
> proposal for decentralized extensibility, then prefixes have fixed  
> meanings, and so I believe this problem goes away.

If we can make RDFa have most of the strengths of Microdata, then that  
would be a good long-term solution, but I don't see that happening  
fast enough to resolve ISSUE-76.

There does seem to be at least one problem of RDFa that is not  
obviously resolved via predefined namespace prefixes, namely that it  
applies namespace prefix resolution to attribute values, resulting in  
what are effectively "QNames in content" (really CURIEs not QNames,  
but many of the same issues arise).

It also seems that if you ever use any non-predefined prefixes, then  
all of the issues with RDFa's use of namespaces (including the  
somewhat un-XML-ish handling of xmlns declarations) would still be  
present, if the ability to use non-predefined prefixes was not  
completely removed.

So, I'm not sure the resolution is that simple. It does seem like a  
matter worth investigating further, but probably outside the scope of  
ISSUE-76.

Regards,
Maciej

>
> What do people think the other big problems with RDFa are? How much  
> do they matter? Are there ways of fixing them?
>
> AFAICT the obvious annoyances with RDFa are:
> ·         Reliance on namespaces – but that can be fixed by the  
> earlier proposal
> ·         RDFa requires you to declare a type to get a blank node.  
> Does this matter? Could it be easily fixed?
> ·         RDFa expects @rel when the data is a link, and @property  
> when it is content – but I quite like that
> ·         RDFa doesn’t have a DOM API – but that can be added
> ·         RDFa requires an extra layer of indirection when putting  
> one node inside another. This is because when a node has a @rel  
> attribute, the node is the subject if the node has a type. Does this  
> matter? Could it be easily fixed?
>
>
> What am I missing?
>
> To make this discussion more concrete, here is are a couple of  
> examples, using the same data, written in Microdata vs RDFa,  
> assuming that we have a fixed set of prefixes, and that we also have  
> a fixed set of standard types and properties that don’t require  
> prefixes.
>
> First, let’s do an example where all the names we use are in the  
> global namespace:
>
> Microdata:
>   <div itemscope>
>     <p>My name is <span itemprop=”name”>Elizabeth</span></p>
>     <img itemprop=”image” src=”liz.png” alt=”My Photo”>
>    Band:
>      <span itemprop=”band” itemscope>
>         <span itemprop=”name”>Jazz Band</span> (<span  
> itemprop=”size”>12</span> players)
>     </span>
>   </div>
>
> RDFa:
>   <div type=”person”>
>     <p>My name is <span property=”name”>Elizabeth</span></p>
>     <img rel=”image” src=”liz.png” alt=”My Photo”>
>     <span rel=”band”>    -- extra node needed
>       <span type=”Band”>
>         <span property=”name”>Jazz Band</span> (<span  
> property=”size”>12</span> players)
>       </span>
>     </span>
>  </div>
>
> Now, an example where we use names from an external vocabulary. In  
> this case, we assume the vocabulary has a registered prefix rather  
> than an experimental prefix:
>
> Microdata:
>   <section itemscope itemtype=”http://example.com/animals#cat”>
>      <h1 itemprop=”name http://example.com/fn”>Hedral</h1>
>   </section>
>
> RDFa with registered prefixes:
>    <section type=”animals:cat”>
>      <h1 itemprop=”name animals:fn”>Hedral</h1>
>    </section>
>
>
> When the namespace problem is taken away, what differences are still  
> problematic?
>
>
> Note that I am not advocating for any particular position. I’m just  
> trying to explore the space.
>
>
> -Rob
>