[whatwg] Trying to work out the problems solved by RDFa

Julian Reschke ha scritto:
> Calogero Alex Baldacchino wrote:
>> ...
>> This is why I was thinking about somewhat "data-rdfa-about", 
>> "data-rdfa-property", "data-rdfa-content" and so on, so that, for the 
>> purposes of an RDFa processor working on top of HTML5 UAs (perhaps in 
>> a test phase, if needed at all, of course), an element dataset would 
>> give access to "rdfa-about", instead of just "about", that is using 
>> the prefix "rdfa-" as acting as a namespace prefix in xml (hence, as 
>> if there were "rdfa:about" instead of "data-rdfa-about" in the markup).
>> ...
>
> That clashed with the documented purpose of data-*.

Hmm, I'm not sure there is a clash, since I was suggesting a *custom* 
and essentially *private* mechanism to experiment with RDFa in 
conjunction with HTML serialization, for the *small-scale* needs of some 
organizations willing to embed RDFa metadata in text/html documents, and 
to exchange them with each other by using a convention likely avoiding 
name clashes with other private metadata. Since I think it's unlikely to 
find data-rdfa-* used with different semantics in the very same page, 
and in a small-scale scenario involving a few *selected* sources for 
RDFa-modelled information, it should be likely to know in advance that 
someone else is using the same conventions. Such a modelled document 
might be used in conjunction with an external RDFa processor, thus 
avoiding any direct support in a browser.

However, such a convention might be enough "clash-free" to work on a 
wider scale, thus it might become widespread and provide an evidence 
that the web /needs/, or at least /has chosen/ to use RDFa as (one of) 
the most common way to embed metadata in a document, and such might be 
enough to add a native support for the whole range of "RDFa" attributes, 
eventually along with support for earlier experimental ones (such as 
"data-rdfa-*" and "rdfa:*" ones, for backward compatibility). And 
actually I can't see much of a problem if a private-born feature became 
the base of a widespread and widely accepted convention (I'm not saying 
the spec should name data-rdfa-* as a mean to implement RDFa, instead I 
think that, if a general agreement on if and how RDFa must be spec'ed 
out and implemented can't be found, such an experiment might be proposed 
to the semantic web industry and wait for the results - given a lack in 
support might prevent any interested party to use RDFa and HTML5 
altogether).

>
> *If* we want to support RDFa, why not add the attributes the way they 
> are already named???
>

For instance, to experiment whether it is worth to change the "if we 
want" into "we do want", without requiring an early implementation and 
specification, nor relying on if and what a certain browser vendor might 
want to experiment differently from others (such a convention would only 
require support for HTML5 datasets and a script or a plugin capable to 
handle them as representing RDFa metadata). -- the point here is that 
after introducing data-* attributes as a mean to support custom 
attributes any browser vendors might decide to drop support for other 
kind of custom attributes in html serialization (that is, for attributes 
being neither part of the language nor data-* ones), therefore if they 
(or any of them) decided to avoid to support RDFa attributes until they 
were introduced in a specification there might be no mean to experiment 
with them (in general, that is cross-browser) without resorting either 
to data-* or to "rdfa:*" (the latter in xhtml).

Anyway, /in general/ what should a browser do with RDFa metadata, on a 
*wide scale*, other than classifying a portion of the open web (e.g. in 
its local history), eventually allowing users to select trusted sources?

Actually, I don't think such would bring enough benefits for *average* 
users, compared to the risk to get a lot of spam metadata from 
/heterogeneous/ sources. I really don't expect average users to 
understand how to filter sites basing on metadata reliability (and just 
for the purpose to use a metadata-based query interface, because a site 
with wrong metadata might still contain usefull informations); instead 
they might just try and use a query interface the same way they use a 
default search bar, get wrong results (once spam metadata became 
widespread) and decide the mechanism doesn't work fine (eventually 
complaining for that). A somewhat antispam filter might help, but I 
think that understanding if metadata are reliable, that is if they 
really correspond to a web page content, is an odd problem to be solved 
by a bot without a good degree of Artificial Intelligence (filtering 
emails by looking for suspicious patterns is far easier than 
implementing a filter capable to /understand/ metadata, /understand/ 
natural language and compare /semantics/ ).

As well, I don't expect the great majority of web pages to contain 
"valid" metadata: most people would not care of them, and a potentially 
growing number might copy&paste code containing metadata from other 
sites as a kind of template, then edit the content and ignore any 
metadata, thus breaking reliability. I do think wide-scale use of 
metadata coming from heterogeneous sources can be more harmful than 
useful. *If* we do agree that small-scale needs is the main context 
where RDFa can bring benefits, perhaps a custom mechanism and external 
plugins are all we need; otherwise, it should be proved that /misused/ 
and /abused/ metadata can be filtered out *easily* and *automatically*, 
without requiring average users to understand the problem, nor affecting 
the overall efficiency. IMHO.

>> ...
>> However, AIUI, actual xml serialization (xhtml5) allows the use of 
>> namespaces and prefixed attributes, thus couldn't a proper namespace 
>> be introduced for RDFa attributes, so they can be used, if needed, in 
>> xhtml5 documents? I think such might be a valuable choice, because it 
>> seems to me RDFa attributes can be used to address such cases where 
>> metadata must stay as close as possible to correspondent data, but a 
>> mistake in a piece of markup may trigger the adoption agency or 
>> foster parenting algorithms, eventually causing a separation between 
>> metadata and content, thus possibly breaking reliability of gathered 
>> informations. From this perspective, a parser stopping on the very 
>> first error might give a quicker feedback than one rearranging 
>> misnested elements as far as it is reasonably possible (not 
>> affecting, and instead improving, content presentation and users' 
>> "direct" experience, but possibly causing side-effects with metadata).
>> ...
>
> That would make RDFa as used in XHTML 1.* and RDFa used in HTML 5 
> incompatible. What for?
>
> > ...
>
> BR, Julian

Because I'm not sure RDFa can work fine with HTML serialization. To 
clarify that, let me take and modify an example from W3C Recommendation 
(without pretending it to be a good example to build a good worst-case 
scenario, but just to give an idea):

[...]
<p>
   I'm holding
   <span property="cal:summary">
     one last summer Barbecue
   </span>, to meet friends and have a party before the end of holidays
   on
   <span property="cal:dtstart" content="2007-09-16T16:00:00-05:00"
         datatype="xsd:dateTime">
     September 16th at 4pm
   </span>.
</p>
[...]


Now let consider it written as:

[...]
<p>
  I'm holding
  <span property="cal:summary">
    one last summer Barbecue
 <!-- now the </span> close tag is missing here -->,
  to meet friends and have a party before the end of holidays
  on
  <span property="cal:dtstart" content="2007-09-16T16:00:00-05:00"
        datatype="xsd:dateTime">
    September 16th at 4pm
  </span>.
</p>
[...]


The above would result in a parse error as an xml-serialized document, 
since the document isn't well formed. Instead, as part of an 
html-serialized document, the above fragment would be processed anyway, 
improving users' experience (with respect to a page stopping rendering 
on a missing close tag), but potentially causing metadata to be 
imprecisely binded to any data, thus potentially harming automated data 
extraction (for some purpose). Therefore, perhaps using such metadata 
only inside xml serialized pages might give a quick feedback on such a 
problem as soon as the author checked a page appearance (which I think 
would be the very first check, as well as I think about no one would 
check the _whole_ range of possible queries people might make over a 
document, to look for errors).

*If* this is meaningful, supporting RDFa attributes as "rdfa:*" might 
ensure that xml serialization is preferred by people really needing to 
use this kind of metadata (while leaving a chance to experiment RDFa 
with html serialization, because no one can be prohibited to use 
data-<prefix>-* for this purpose beside a proper script or plugin), 
whereas introducing "about", "property", "content", "datatype" and so on 
directly in html namespace, as attributes shared by all elements, would 
make the choice of one serialization or the other indifferent, thus 
leading to every possible side-effects html serialization may cause.

As a side note, It seems that people from the W3C are evaluating a 
resort to extensibility to introduce RDFa attributes into xml-serialized 
html documents, and they also have some doubts whether allow use of RDFa 
attributes within html serialization or not:

"The HTML WG is encouraged to provide a mechanism to permit 
independently developed vocabularies such as Internationalization Tag 
Set (ITS), Ruby, and RDFa to be mixed into HTML documents. /Whether this 
occurs through the extensibility mechanism of XML, *whether it is also 
allowed in the classic HTML serialization*, and whether it uses the DTD 
and Schema modularization techniques/, is for the HTML WG to determine."
(from <http://www.w3.org/2007/03/HTML-WG-charter#deliverables>)

WBR, Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Meetic: il leader italiano ed europeo per trovare l'anima gemella online. Provalo ora
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8291&d=9-1

Received on Friday, 9 January 2009 12:07:47 UTC