microdata/rdfa wishlist

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

microdata/rdfa wishlist

Benjamin Nowack-2

Hi all,

I just had a phone chat with Manu and he suggested that I send
my ideas to the list if I want them to be considered.

However, the longer I think about the whole situation, the more
I feel that there's a need for two separate approaches. Manu
said that there are cases that "just don't work" with something
like Microdata and that require the full power of RDFa. On the
other hand, there is a huge target audience for semantic markup
that so far have rejected RDFa and seem to want a simpler
solution.

I know, I'm an RDFer, but my background when I started exploring
RDF in 2003 was exactly that audience mentioned above, web agency
and freelance work, and after a looong journey through the RDF
spec forest, I'm now slowly returning to my roots, but equipped
with a selection of powerful SemWeb technologies that I found to
work great for my clients, tools, and projects (all around web
site and app development). And for my use cases, Microdata seems
to become more convenient than RDFa.

So, here is my very personal view of things that I would love
the Semantics-in-HTML people within W3C to consider:
* align the RDFa attributes to those of Microdata and
   * disallow hidden links via @resource,
   * move from ugly to ugly-but-consistent attribute names ;)
   * make resource description boundaries explicit
* disallow CURIEs or similar indirection mechanisms that are
  tricky in publishing systems based on nested templates and which
  make JavaScript access more complicated than necessary.
* turn RDFa into a syntactic superset of Microdata.
* maybe: reduce the HTML part of Microdata to Model, Syntax,
  and DOM API, let the relevant RDF group contribute to an RDF
  mapping.
* a consistent vocabulary/itemtype approach for Microdata
  (via XMDP, RDF Schema, or somesuch), possibly with a set
  of pre-defined vocabs/types like vcard, cal, or dc stuff.
* buy my new single!

I know, I'm asking too much.

Fallback list:
* accept that there are different needs, which - as sad as it
  may be - require two different solutions (with poor me
  somewhere in between).


Cheers,
Benji

--
Benjamin Nowack
http://bnode.org/
http://semsol.com/