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

[Calogero Alex Baldacchino]

Charles McCathieNevile ha scritto:
> On Sun, 04 Jan 2009 03:51:53 +1100, Calogero Alex Baldacchino 
> <alex.baldacchino at email.it> wrote:
>
>> Charles McCathieNevile ha scritto:
>> ... it shouldn't be too difficoult to create a custom parser, 
>> comforming to RDFa spec and availing of data-* attributes...
>>
>> That is, since RDFa can be "emulated" somehow in HTML5 and tested 
>> without changing current specification, perhaps there isn't a strong 
>> need for an early adoption of the former, and instead an "emulated" 
>> mergence might be tested first within current timeline.
>
> In principle this is possible. But the data-* attributes are designed 
> for private usage, and introducing a public usage means creating a 
> risk of clashes that pollute RDFa data gathered this way. In other 
> words, this is indeed feasible, but one would expect it to show that 
> the data generated was unreliable (unless privately nobody is 
> interested in basic terms like about). 

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).

This way, the public exposure of RDFa attributes on top of the generic 
and normally-private dataset feature might be enough circumscribed to 
avoid clashes. That is, if RDFa shows its best benefits when used to 
address small-scale needs involving trusted/reliable (meta-)data, it 
should be fair to assume all involved parties are aware that each one is 
using RDFa, and aren't just running an RDFa processor in the hope to 
gather enough informations.

 From this point of view, it should be quite unlike to find people using 
"data-rdfa-about" to express different semantics in the same page 
(whereas data-property might cause ambiguity, for instance), as well as 
it is (or should be) quite unlike to find namespaces using the very same 
prefix involved in the same xml document (that is, I think choosing a 
name including a namespace prefix for a data-* attribute (and also for a 
class in a generic container as a div or a span, to tell it represents 
an external element) can replicate quite safely the xml extensibility 
for custom uses, to some extent, without requiring a wide support for it 
in text/html document - since it seems that xhtml extensibility is not a 
major concern, at least not enough to be worth merging it into html).

Just an idea, though.

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).

Also, if the above is true, using namespaced and prefixed attributes 
instead of ones laying in the same namespace shared both by html5 and by 
xhtml5 (in theory) might prevent the use of such metadata in a document 
whose parsing rules might lead to possible side-effects.

> Such results have been used to suggest that poorly implemented 
> features should be dropped, but this hypothetical case suggests to me 
> that the argument is wrong, and that if in the face of reasons why the 
> data would be bad people use them, one might expect better usage by 
> formalising the status of such features and getting decent 
> implementations.
>

Generally speaking, I think reasoning in terms of "poor implementation" 
vs "rare usage" is quite like moving as a dog biting his own tail, 
because poorly implemented features are forcedly rarely used, and rarely 
used features can't convince UAs developers to implement them (in 
general). But, if a feature is widely needed, several hacks may born, 
thus providing an evidence of a global problem to be solved in a certain 
manner by implementing a certain, well-conceived feature.

As far as I've understood it, that's the main guideline to change actual 
specification, which is moving on the base of a bullet-tracing evolution 
(perhaps weighted on the need for completely new features, as a balance 
between the need for innovation and that for backward compatibility), 
rather than a "cathedral-wise" definition of what is or can be a useful 
feature to be implemented. For this reason, I think that mapping RDFa 
attributes on data-rdfa-* attributes to experiment a convergence between 
RDFa attributes and html5 specific features might be a start point to 
get RDFa attributes both specified and widely supported by 
implementations (either as they're defined in W3C Recommendation, or in 
the form of data-rdfa-*, hence dealt with differently from data-* 
attributes, for backward compatibility with such early implementations - 
a slightly different (or somehow prefixed) name shouldn't be much of a 
problem, as far as the name is not a problem per se (e.g. it is not 
prone to clashes) and allows a one-to-one correspondence).

However, if a custom/small scale solution met a wide support and a deep 
integration into major browsers, maybe misuses and abuses (which a 
proper formalisation couldn't prevent) might become widespread, thus 
making disadvantages (appear or be) greater than advantages, if measured 
on a wider scale (the same as the implementation). Therefore, I think a 
good start point can consist of partly introducing support on top of 
existing features (in the case of RDFa, either through well-groomed, 
custom data-* attributes in html5, or by defining a proper namespace 
with a proper prefix for xhtml5), without requiring a deep integration 
of a processor for the new feature, but instead letting it be a (custom) 
plugin/extension, or an api for a (custom) web application needing it - 
since a person just wishing to get access to some content without caring 
of metadata and metadata reliability could just visit a page, while an 
organisation wishing to interchange RDFa modelled data with another one 
can run a separate processor (eventually a webapp based on a browser 
built-in API, or a plugin, to create a suitable interface for queries) 
to extract and merge informations.

>>>> What is the cost of having different data use specialised formats?
>>>
>>> If the data model, or a part of it, is not explicit as in RDF but is 
>>> implicit in code made to treat it (as is the case with using scripts 
>>> to process things stored in arbitrarily named data-* attributes, and 
>>> is also the case in using undocumented or semi-documented XML 
>>> formats, it requires people to understand the code as well as the 
>>> data model in order to use the data. In a corporate situation where 
>>> hundreds or tens of thousands of people are required to work with 
>>> the same data, this makes the data model very fragile.
>>>
>>
>> I'm not sure RDF(a) solves such a problem. AIUI, RDFa just binds 
>> (xml) properties and attributes (in the form of curies) to RDF 
>> concepts, modelling a certain kind of relationships, whereas it 
>> relies on external schemata to define such properties. Any 
>> undocumented or semi-documented XML formats may lead to misuses and, 
>> thus, to unreliably modelled data,
> ...
>
>> I think the same applies to data-* attributes, because _they_ 
>> describe data (and data semantics) in a custom model and thus _they_ 
>> need to be documented for others to be able to manipulate them; the 
>> use of a custom script rather than a built-in parser does not change 
>> much from this point of view.
>
> RDFa binds data to RDF. RDF provides a well-known schema language with 
> machine-processable definition of vocabularies, and how to merge 
> information between them. In other words, if you get the underlying 
> model for your data right enough, people will be able to use it 
> without needing to know what you do.
>
> Naturally not everyone will get their data model right, and naturally 
> not all information will be reliable anyway. However, it would seem to 
> me that making it harder to merge the data in the first place does not 
> assist in determining whether it is useful. On the other hand, certain 
> forms of RDF data such as POWDER, FOAF, Dublin Core and the like have 
> been very carefully modelled, and are relatively well-known and 
> re-used in other data models. Making it easy to parse this data and 
> merge it, according to the existing well-developed models seems valuable.
>

I admit I'm not very expert in RDF use, thus I have a few questions. 
Specifically, maybe I can guess the advantages when using the same 
(carefully modelled, and well-known) vocabulary/ies; but when two 
organizations develop their own vocabularies, similar yet different, to 
model the same kind of informations, is merging of data enough? Can a 
processor give more than a collection of triples, to be then interpreted 
basing on knowledge on the used vocabulary/ies?

I mean, I assume my tools can extract RDF(a) data from whatever 
document, but my query interface is based on my own vocabulary: when I 
merge informations from an external vocabulary, do I need to translate 
one vocabulary to the other (or at least to modify the query backend, so 
that certain curies are recognized as representing the same concepts - 
e.g. to tell my software that 'foaf:name' and 'ex:someone' are 
equivalent, for my purposes)? If so, merging data might be the minor 
part of the work I need to do, with respect to non-RDF(a) metadata (that 
is, I'd have tools to extract and merge data anyway, and once I 
translated external metadata to my format, I could use my own tools to 
merge data), specially if the same model is used both by mine and an 
external organization (therefore requiring an easier translation).

Thus, I'm thinking the most valuable benefit of using RDF/RDFa is the 
sureness that both parties are using the very same data model, despite 
the possible use of different vocabularies -- it seems to me that the 
concept of triples consisting of a subject, a predicate and an object is 
somehow similar to a many-to-many association in a database, whereas one 
might prefer a one-to-many approach - though, the former might be a 
natural choice to model data which are usually sparse, as in a document 
prose.

>
>>> Ian wrote:
>>>> For search engines, I am not convinced. Google's experience is that
>>>> natural language processing of the actual information seen by the 
>>>> actual end user is far, far more reliable than any source of metadata.
>>>> Thus from Google's perspective, investing in RDFa seems like a poorer
>>>> investment than investing in natural language processing.
>>>
>>> Indeed. But Google is something of an edge case, since they can 
>>> afford to run a huge organisation with massive computer power and 
>>> many engineers to address a problem where a "near-enough" solution 
>>> brings themn the users who are in turn the product they sell to 
>>> advertisers. There are many other use cases where a small group of 
>>> people want a way to reliably search trusted data.
>>>
>>
>> I think the point with general purpose search engines is another one: 
>> natural language processing, whereas being expensive, grants a far 
>> more accurate solution than RDFa and/or any other kind of metadata 
>> can bring to a problem requiring data must never need to be trusted 
>> (and, instead, a data processor must be able to determine data's 
>> level of trust without any external aid).
>
> No, I don't think so. Google searches based on analysis of the open 
> web are *not* generally more reliable than faceted searches over a 
> reliable dataset, and in some instances are less reliable.
>
> The point is that only a few people can afford to invest in being a 
> general-purpose search engine, whereas many can afford to run a 
> metadata-based search system over a chosen dataset, that responds to 
> their needs (and doesn't require either publishing their data, or 
> paying Google to index it).
>

My point is that possible assumptions over datasets reliability is the 
borderline between wide-scale data extraction/classification, which is 
the main problem solved by a general purpose search engine, and implies 
the best assumption by default is datasets reliability is uncertain, and 
(very) small-scale data modelling, were a direct and immediate 
evaluation over datasets reliability is possible and easy to do, so that 
a custom search engine could reliably be based on such metadata. I think 
no comparison is possible between the two scales, thus no generalization 
is possible when trying to guess whether metadata can do more good than 
harm, but instead each case should be analysed separately, and everyone 
should agree which one is the best context (eventually both) where RDFa 
should be used, to understand what's the best way to implement it and if 
it's worth to be introduced in html5 -- as far as I can tell, both of us 
agree that small-scale is the main context.

But perhaps some edge-side case should be considered to draw a better 
picture. For instance, one such case might be a browser availing of 
metadata to search a resource in its local history, or within a web page 
and related/linked pages (to a certain digree and level of depth), 
because its scale would be small with respect to the effective number of 
scanned resources, but wide with respect to the potential number of 
sources for those resources, that is, because a browser implementing a 
metadata extraction and merging engine and a query interface to look for 
gleaned informations would deal with a | limited number | of | 
etherogeneous sources | at a given time.

Once major browsers provided (and exposed by default) such a 
functionality, a growing number of users would (try and) use it, thus a 
growing number of sites would experiment metadata. At the beginning 
everything might work fine, since only honest sites would experiment 
honest metadata (such as wikis, for instance), but once the number of 
sites and users availing of metadata reached a threshold point spammers 
would start including spam metadata in their sites (with otherwise 
trustful content) and in other sites through advertisements. Such a 
scenario might lead to a bad balance between benefits and disadvantages 
for the average user, thus pushing (some) browser vendors to limit or 
even to wholly drop native support, and I guess this is not a wishable 
solution for the Semantic Web Industry.

That is, choosing a proper level of integration for RDF(a) support into 
a web browser might divide success from failure. I don't know what's the 
best possible level, but I guess the deepest may be the worst, thus 
starting from an external support through out plugins, or scripts to be 
embedded in a webbapp, and working on top of other feature might work 
fine and lead to a better, native support by all vendors, yet limited to 
an API for custom applications -- whereas any changes to html to include 
RDFa attributes would be fully meaningful if leading to a full support 
and exposed features to avail of metadata, which I don't think is much 
of a benefit for the great majority of (home) users.

Everything, IMHO

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