W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > April 2011

Comments on the current version of the RDFa Primer

From: Benjamin Adrian <benjamin.adrian@dfki.de>
Date: Fri, 08 Apr 2011 15:19:32 +0200
Message-ID: <4D9F0B64.5070000@dfki.de>
To: Ivan Herman <ivan@w3.org>, ben@adida.net, Mark Birbeck <mark.birbeck@webbackplane.com>
CC: RDFa WG <public-rdfa-wg@w3.org>
Hi Ben, Ivan and Mark

You did a great job when writing this Primer. I enjoyed reading it.
Nevertheless, I found some confusing sentences and minor bugs.
They are listed below from a) to i) :

In general, I could not find any references to the RDFa API in this 
Primer. Is this intended? If you want I can create small code samples 
for the used examples on Monday (my wife celebrates her birthday this 
weekend :) ).

My PhD supervisor always reminds me to refer to existing figures from 
text. I don't know if this should also be done here. But I think it 
won't cause much effort and in case of broken links to these images it 
would give readers a hint that something is missing.

a) In Section 2.2.2 about profiles you criticise the Google approach of 
inventing new vocabularies and mention the v:name and the foaf:name 
property. In my opinion this is a confusing motivation for profiles.
I fear, ordinary RDFa authors won't get our point here. It also 
highlights the problem what Alice would do if she likes to use both 
foaf:name and v:name. I think we should focus on saying:

"2.2.2 Preparing vocabulary bundles, a.k.a. profiles
RDFa 1.1 introduces the idea of bundling vocabularies into a single 
profile, making it particularly easy for HTML authors to combine the use 
of multiple vocabularies with markup as simple as the single-vocabulary 
use case."

b) In Section about Default profiles you state that:
"Relying on default profiles is very convenient, but may also cause 
problems and affect the readability of the RDFa code"
I don't think it is a good idea to implicitly deprecate the use of 
default profiles in the primer. Either we remove default profiles from 
the primer or I propose let us remove just this passage.

c) In Section 2.3.2 about the Social Network example you state that:
"Alice is tired of repeatedly entering information about her friends in 
each new social networking sites. With RDFa, she can indicate her 
friendships on her own web page, and let social networking applications 
read it automatically."
Well, indeed this is inspiring, and a great use case of RDFa and Linked 
Data. But what if someone else declares on his web site that Alice knows 
him. It would be awful if this gets into a social networking site like 
Facebook automatically. As this was my first thought after reading this 
paragraph, I fear we should better remove it until the Provenance WG 
generated a solution to this dilemma :) .

d) Just before Section 2.4.1 Custom Vocabularies we mention:
RDFa is a way to express RDF data within XHTML, ...
This should be corrected to HTML.

e) 2.5.1 Importing Data
In the Primer we should refer to Javascript instead of ECMAScript.

e1) I don't see any reason not to mention the RDFa API here.
e.g., Amy also uses the RDFa API to automatically extract the event 
information from a page and some additional ECMAScript code that she 
found on the web to add an entry into a personal calendar.

e2) Here is an encoding problem at: "Brian finds AmyÆs ... bandÆs page

f) 2.5.2 Data-based Web Page Modification
The text ends up to early here. We should add the sentence:
"He writes a few lines of Javascript code by using the RDFa API to 
extract the URI of the applied license in order to look up a dictionary 
for the correct icon of this license."

g) 2.5.3 about Automatic Summaries
The example is buggy:
<span property="foaf:name" content="Bob">My<span> interests are:
<span property="foaf:name" content="Bob">My</span> interests are:

g1) Please consider to add the sentence:
"Finally Mary usses the RDFa API to extract this kind of information 
from the HTML source in order to populate the infoboxes."

h) 2.5.4. Data Visualization
The sentence:
"This enables him to build on top of the structured data in the page as 
well as letting visitors to the site use the same data to create 
innovative new applications based on the address information in the page."
confused me, but unfortunately I am unable to propose a better solution.

i) Finally, the SVG graphics like very nice. But scrolling the document 
in Firefox 3.6 is horrible slow. Chrome is fast as usual. Maybe we 
should think of using PNG format instead.



Benjamin Adrian
Email : benjamin.adrian@dfki.de
WWW : http://www.dfki.uni-kl.de/~adrian/
Tel.: +49631 20575 1450
Twitter: http://twitter.com/BenBanBun
Skype: benbanbun
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Received on Friday, 8 April 2011 13:20:01 UTC

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