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

[Benjamin Hawkes-Lewis]

On 4/2/09 03:15, Calogero Alex Baldacchino wrote:

For what concerns XHTML, I disagree with the introduction of RDFa
attribute into the basic namespace, and I wouldn't encourage the same in
HTML5 spec. In first place, I think there is a possible conflict with
respect to the "content" attribute semantics, because it now requires a
different processing when used as an RDFa attribute and as a 
attribute associated to an "http-equiv" or a "name" value (for instance).


What conflict?

1. Attributes in XHTML can be distinguished by the elements they apply 
to as well as their name (e.g. the "name" attribute).


2. In XHTML+RDFa, "content" actually means the same thing on "meta" as 
on any other element in XHTML, which is presumably why they reused that 
attribute rather than introducing a new (better-named?) one:


http://www.w3.org/TR/rdfa-syntax/#rdfa-attributes


In second place, it might be confusing for authors and lead to the
misconception that every xhtml 1.x processor is also capable to process
rdfa metadata (this is a limit of namespace + dtd/schema based
modularization, because one can define the structure of a document, but
not "orthogonal" behaviours requiring a specific support, not covered by
the basic document model - such as collecting rdf triples declared by
rdfa attributes, or calling a plugin and embedding its output - however,
defining a proper namespace, maybe including its creation date somehow,
may suggest what to expect from UAs).


There's no way to query a user agent about support for the 
specifications associated with a particular namespace, and namespaces 
are an unreliable guide to what user agents actually support, so I don't 
buy this concern.


Existing XHTML 1.x user agents don't always implement all the features 
of XHTML 1.x (e.g. exposing "longdesc" and "cite" to the user). HTML5 is 
introducing new elements and attributes into the same namespace, and 
authors would be wrong to assume that any XHTML-supporting browser will 
know what to do with them beyond inserting them into the DOM. XHTML 
modularization means you can't count on an XHTML user agent to implement 
any particular feature in the XHTML namespace.


A more reliable guide to what user agents support is looking at the list 
of supported features (as opposed to namespaces or modules or any other 
proxy) in their documentation.



In third place, creating a different namespace would have resulted in a
far easier introduction of RDFa attributes into other xml languages
without having to change the language to host them (by the way, the
xhtml namespace and a related prefix can be used, but this require a
more specific support due to the "content" attribute issue, especially
by UAs not supporting DTDs or schemata - that is, what should happen if
an element were declared with both xhtml:name or xhtml:http-equiv,
xhtml:content and xhtml:datatype, in an xml document accepting any
attributes from external namespaces?


I cannot understand how RDFa attributes in a different namespace would 
be easier to reuse either in another language or a XML document where 
the host is not XHTML.


"content" and "datatype" mean the same on all elements, so your 
particular example seems like a non-problem to me - at least from the 
perspective of RDFa, which doesn't define processing for "name" or 
"http-equiv".


In so far as there is a problem, it's already a problem with 
bog-standard XHTML. How should xhtml:http-equiv="baz" xhtml:content="quux"> be processed?



of course, this is solvable, but
rdfa:content, rdfa:datatype and so on would make things easier, or at
least _cleaner_ and less confusing for authors having to understand that
an XML and RDF processor can/must support the xhtml namespace and its
_whole_ semantics, not just dom-related structures, but limited to RDFa
attributes, so that no  or  or  can be used hoping
their semantics is supported, despite the support for the xhtml
namespace...).


An "XML and RDF processor" doesn't have to support XHTML or RDFA - XML 
and RDF are independent specifications.


A conforming XHTML+RDFa UA "user agent MUST support all of the features 
required in this specification. A conforming user agent must also 
support the User Agent conformance requirements as defined in XHTML 
Modularization [XHTMLMOD] section on "XHTML Family User Agent Conformance".


http://www.w3.org/TR/rdfa-syntax/#uaconf

Those further requirements can be read at:

http://www.w3.org/TR/xhtml-modularization/conformance.html#s_conform_user_agent

An XHTML+RDFa conforming user agent does not have to implement "meta", 
"object", or "link", and as a explained above, authors cannot assume 
support for particular features based on namespaces.



Also there might have been fewer attributes, each one
with a different semantic (assuming someone might not find useful to
have a link with rel="stylesheet" representing a triple, for instance).


I don't follow. link with rel="stylesheet" _does_ represent information 
expressible 

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

[Calogero Alex Baldacchino]

Toby A Inkster ha scritto:


Another reason the Microformat experience suggests new attributes are 
needed for semantics is the overloading of an attribute (class) 
previously mainly used for private convention so that it is now used 
for public consumption.


Maybe this is true, but, personally, I prefere this approach to the 
addition of new features/attributes/elements to an official 
specification without a clear support requirement for UAs beside just 
parsing. A similar (if not stronger) argument may be raised against the 
reuse of the content attribute in the context of RDFa, which I think has 
caused a significant change with respect to its original semantics (now 
it should be shared by every element, originally it was a  
specific attribute; now it should be part of an RDF _triple_, in origin 
it was - and is still - part of a _pair_ when used in conjunction with 
the "name" attribute, and constitutes a pragma directive in conjunction 
with the "http-equiv" attribute, which is somehow closer to an XML 
processing instruction than to an RDF triple - the same applies to a 
 with rel="stylesheet", for instance).


Yes, in real life, there are pages that use class="vcard" for things 
other than encoding hCard. (They mostly use it for linking to VCF 
files.) Incredibly, I've even come across pages that use class="vcard" 
for non-hCard uses, *and* hCard - yes, on the same page! As the 
Microformat/POSHformat space becomes more crowded, accidental 
collisions in class names become ever more likely.




Indeed, that's a possible source of troubles. I think that's the same if 
people misused prefixes, e.g. if after merging some content from 
different documents they got a different namespace binded to a 
previously declared prefix in a scope where both namespaces are involved 
(in an xhtml document). Also, a custom script may distinguish between 
different uses of "vcard" by the mean of a further, private classname, 
or by enveloping elements in containers (divs) with proper ids, which 
may be a good solution in some cases, and not in other ones; a more 
generic parser, being specialized by design, has a chance to recognize a 
correct structure for a given format and to discard wrong informations, 
which may work fine in some cases, but not in others. As always, each 
choice has its own downsides, and what counts is the costs/benefits 
ratio; it seems that any solution not requiring to be supported has the 
lowest costs for UA implementors.


I do not doubt xml extensibility (which effectively is the base of 
curies) has its own benefits, it's flexible and suitable for a quick 
developement of custom solutions, but it's also got its own downsides, 
such as leading to a possible heavy fragmentation, being difficoult to 
understand and use for many people (who are usually fooled by the 
concept of namespaces) and thus potentially causing misuses and errors. 
It doesn't seems that xml extensibility brought more benefits than 
costs, and a proof can lay in the majority of the web not having 
followed the envisioned xml-alike evolution.


Anyway, I'm not strongly against RDFa in HTML, instead, I can be quite 
neutral (I'd live with it); I'm not convinced it is worth to add it to 
the spec at this stage and until it would be possible to establish what 
UAs must do with them beside parsing (and how to deal with namespaces 
while parsing). Also, I'm not fully convinced by the need to embed 
metadata in a page and keep them in sync with that page. For instance, 
it require that every page reporting the same informations must 
duplicate the same metadata structure, and this doesn't grant that those 
informations, in first place, are in sync with real world (some pages 
might be out-of-date, others might be up-to-date). Instead, a separate 
file containing metadata to be linked when appropriate might solve both 
the problems: it doesn't require duplicates and can have a somewhat 
versioning to keep trace of changes and to present updated 
machine-friendly information to help users visiting an outdated page 
(assuming users can trust those metadata). Of course, this solution has 
its own downsides too.


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:
Blu American Express: gratuita a vita! 
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8615&d=4-2

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

[Calogero Alex Baldacchino]

Benjamin Hawkes-Lewis ha scritto:

On 12/1/09 20:26, Calogero Alex Baldacchino wrote:

I just mean that, as far as I know, there is no official standard
requiring UAs to support (parse and expose through the DOM) attributes
and elements which are not part of the HTML language but are found in
text/html documents.


Perhaps, but then prior to HTML5, much of what practical user agents 
must do with HTML has not been required by any official standard. ;)


RFC 2854 does say that "Due to the long and distributed development of 
HTML, current practice on the Internet includes a wide variety of HTML 
variants. Implementors of text/html interpreters must be prepared to 
be 'bug-compatible' with popular browsers in order to work with many 
HTML documents available the Internet."


http://tools.ietf.org/html/rfc2854

HTML 4.01 does recommend that "[i]f a user agent encounters an element 
it does not recognize, it should try to render the element's content" 
and "[i]f a user agent encounters an attribute it does not recognize, 
it should ignore the entire attribute specification (i.e., the 
attribute and its value)".


http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.2

Clearly these suggestions are incompatible with respect to attributes; 
AFAIK all popular UAs insert unrecognized attributes into the DOM and 
plenty of web content depends on that behaviour.




Very, very true. HTML 4.01 also says the recommended behaviours are ment 
"to facilitate experimentation and interoperability between 
implementations of various versions of HTML", whereas the "specification 
does not define how conforming user agents handle general error 
conditions, including how user agents behave when they encounter 
elements, attributes, attribute values, or entities not specified in 
this document", and since "user agents may vary in how they handle error 
conditions, authors and users must not rely on specific error recovery 
behavior". I just think the last sentence defines a best practice 
everyone should follow instead of relying on a common quirk supporting 
invalid markup. However, beside something being a good or bad practice, 
there will always be authors doing whatever they please, therefore it is 
quite safe to assume UAs will always expose invalid/unrecognized 
attributes (that's unavoidable, given the need for backward compatibility).




Just like proprietary elements/attributes introduced with user agent 
behaviours (marquee, autocomplete, canvas), scripted uses of "data-*" 
might suggest new features to be added to HTML, which would then 
become requirements for UAs.


But unlike proprietary elements/attributes introduced with user agent 
behaviors, scripted uses of "data-*" do not impose new processing 
requirements on UAs.


Therefore, unlike proprietary elements/attributes introduced with user 
agent behaviors, scripted uses of "data-*" impose _no_ design 
constraints on new features.


Establishing user agent behaviours with "data-*" attributes, on the 
other hand, imposes almost as many design constraints as establishing 
them with proprietary elements and attributes. (There's just less 
pollution of the primary HTML "namespace".)


If no RDFa was in deployment, you could argue it would be less wrong 
(from this perspective) to abuse "data-*" than introduce new attributes.


Oh, well, I don't want to argue about that. For me the idea to use 
"data-rdfa-*" can rest in peace, since in practice it's not different 
from using RDFa attributes as they are, at least as far as they're 
handled by scripts, either client- or server-side. However I think that,


* actually it seems not to be enough clear what UAs not involved in a 
particular project should do with RDFa attributes, beside exposing their 
content for the purpose of a script elaboration, whereas a precise 
behaviour should be defined, as well as an eventual class of UAs clearly 
identified as not required to support it, and eventual caveats on 
possible problems and relative solutions, before introducing any new 
elements/attributes in a formal specification;


* actual deployment might be harmed by the use of xml namespaces in html 
serialization.


Also, I see design suggestions more than impositions. If a new (and 
proprietary/private) attribute/element/convention is convincingly 
useful/needed, it is supported by other UAs and introduced in a 
specification, otherwise, if a not enough significant number of pages 
would be broken, it might even be redefined for use with a different 
semantics. And a possible process involving data-* attributes 
would/could be experiment privately => extend the scale involving other 
people finding it useful for their needs => get it in the primary 
namespace of an official specification (discarding the "data-" part and 
any other useless parts of the experimental name), so that existing 
pages may still work with their custom scripts or easily migrate to the 
new standard (and benefit of the new default support) by 

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

[Andi Sidwell]

On 2009-01-12 23:15, Toby A Inkster wrote:

Henri Sivonen wrote:


eRDF is very different in not relying on attributes whose qname
contains the substring "xmlns".



eRDF is very different in that it is incredibly annoying to use in real
world scenarios (i.e. not hypothetical "Hello World" examples).

Calogero Alex Baldacchino wrote:


I guess closing a language to every kind of "back-door changes" may be
in contrast with the principle of paving a cawpath. I also guess that,
if microformats experience (or the "realworld semantics" they claim to
be based on) had suggested the need to add a new element/attribute to
the language, a new element/attribute would have been added.


But Microformats experience *does* suggest that new attributes are
needed for semantics. Look at the debate around accessibility within
Microformats which has been going on for ages. Because of the
Microformats process of working *within* existing HTML standards it has
not been solved, and I can't see a solution reaching consensus in the
foreseeable future. HTML5's  goes part of the way to solving this,
but it doesn't address the whole problem like RDFa's "content" attribute
does.


Right, so some microformats brought to attention a need which HTML5 
could easily solve by adding .  Why does this mean that RDFa 
should be added?



Another reason the Microformat experience suggests new attributes are
needed for semantics is the overloading of an attribute (class)
previously mainly used for private convention so that it is now used for
public consumption.


But HTML4 itself says that class can be used "for general purpose 
processing by user agents", so this seems to be a weird argument.  If we 
introduced RDFa and it got used, would you argue you need something more 
than RDFa, because it is being used for what it is specced for?



Yes, in real life, there are pages that use
class="vcard" for things other than encoding hCard. (They mostly use it
for linking to VCF files.) Incredibly, I've even come across pages that
use class="vcard" for non-hCard uses, *and* hCard - yes, on the same
page! As the Microformat/POSHformat space becomes more crowded,
accidental collisions in class names become ever more likely.


Right, but is it much of an issue?  If you have a hCard extractor, the 
user can see easily that it's not useful data.  And if doesn't follow 
any of the other rules for an hCard, then the UA can safely ignore it 
(e.g. it has no fields).  In practice, this kind of collision seems 
fairly non-problematic.



The Microformats community hasn't added any new attributes for
Microformats, because that was one of the guiding principles when the
community was established: however, that does not mean it hasn't shown
that new attributes are needed for encoding rich semantics in HTML. On
the contrary, I think it's proved that they are.


Given that the only example of the microformats process needing an 
addition to the HTML language has been , I'm not sure that's a 
conclusive proof.


Andi

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

[Toby A Inkster]

Henri Sivonen wrote:


eRDF is very different in not relying on attributes whose qname
contains the substring "xmlns".



eRDF is very different in that it is incredibly annoying to use in  
real world scenarios (i.e. not hypothetical "Hello World" examples).


Calogero Alex Baldacchino wrote:


I guess closing a language to every kind of "back-door changes" may be
in contrast with the principle of paving a cawpath. I also guess that,
if microformats experience (or the "realworld semantics" they claim to
be based on) had suggested the need to add a new element/attribute to
the language, a new element/attribute would have been added.


But Microformats experience *does* suggest that new attributes are  
needed for semantics. Look at the debate around accessibility within  
Microformats which has been going on for ages. Because of the  
Microformats process of working *within* existing HTML standards it  
has not been solved, and I can't see a solution reaching consensus in  
the foreseeable future. HTML5's  goes part of the way to  
solving this, but it doesn't address the whole problem like RDFa's  
"content" attribute does.


Another reason the Microformat experience suggests new attributes are  
needed for semantics is the overloading of an attribute (class)  
previously mainly used for private convention so that it is now used  
for public consumption. Yes, in real life, there are pages that use  
class="vcard" for things other than encoding hCard. (They mostly use  
it for linking to VCF files.) Incredibly, I've even come across pages  
that use class="vcard" for non-hCard uses, *and* hCard - yes, on the  
same page! As the Microformat/POSHformat space becomes more crowded,  
accidental collisions in class names become ever more likely.


The Microformats community hasn't added any new attributes for  
Microformats, because that was one of the guiding principles when the  
community was established: however, that does not mean it hasn't  
shown that new attributes are needed for encoding rich semantics in  
HTML. On the contrary, I think it's proved that they are.


--
Toby A Inkster

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

[Benjamin Hawkes-Lewis]

On 12/1/09 20:26, Calogero Alex Baldacchino wrote:

I just mean that, as far as I know, there is no official standard
requiring UAs to support (parse and expose through the DOM) attributes
and elements which are not part of the HTML language but are found in
text/html documents.


Perhaps, but then prior to HTML5, much of what practical user agents 
must do with HTML has not been required by any official standard. ;)


RFC 2854 does say that "Due to the long and distributed development of 
HTML, current practice on the Internet includes a wide variety of HTML 
variants. Implementors of text/html interpreters must be prepared to be 
'bug-compatible' with popular browsers in order to work with many HTML 
documents available the Internet."


http://tools.ietf.org/html/rfc2854

HTML 4.01 does recommend that "[i]f a user agent encounters an element 
it does not recognize, it should try to render the element's content" 
and "[i]f a user agent encounters an attribute it does not recognize, it 
should ignore the entire attribute specification (i.e., the attribute 
and its value)".


http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.2

Clearly these suggestions are incompatible with respect to attributes; 
AFAIK all popular UAs insert unrecognized attributes into the DOM and 
plenty of web content depends on that behaviour.



Reuse of "data-*" by DHTML widgets would not impose any additional
requirements on user agents, so it would be fine from the perspective
elaborated above. It wouldn't change the language by the back door.


Really? Is it so much different from the case of the pattern attribute
(which addresses, at the UA and language level, a problem earlier solved
by scripts -- e.g. getting elements by their ids)? I don't think it's
very different. From this perspective, if data-* attributes existed
before the pattern attribute, someone might have used them to declare a
regex then used by a script implementing a generic checking, and such
might have been a good reason to add the pattern attribute to form
inputs, requiring UAs to contrast the input value to its relative
regular expression (a solution wich also works for UAs not supporting
scripts, for instance).


Just like proprietary elements/attributes introduced with user agent 
behaviours (marquee, autocomplete, canvas), scripted uses of "data-*" 
might suggest new features to be added to HTML, which would then become 
requirements for UAs.


But unlike proprietary elements/attributes introduced with user agent 
behaviors, scripted uses of "data-*" do not impose new processing 
requirements on UAs.


Therefore, unlike proprietary elements/attributes introduced with user 
agent behaviors, scripted uses of "data-*" impose _no_ design 
constraints on new features.


Establishing user agent behaviours with "data-*" attributes, on the 
other hand, imposes almost as many design constraints as establishing 
them with proprietary elements and attributes. (There's just less 
pollution of the primary HTML "namespace".)


If no RDFa was in deployment, you could argue it would be less wrong 
(from this perspective) to abuse "data-*" than introduce new attributes.


But to the extent that these attributes are already in use in text/html 
and standardized within the "http://www.w3.org/1999/xhtml"; namespace, 
processing requirements are effectively already being imposed on user 
agents (such as not introducing conflicting treatment of the "about" 
attribute). All that adding user agent behaviours with "data-rdfa*" 
attributes would do at this point is add _more_ requirements, without 
rescuing the polluted attributes.


> I also guess that,

if microformats experience (or the "realworld semantics" they claim to
be based on) had suggested the need to add a new element/attribute to
the language, a new element/attribute would have been added.


I'm not really sure what you mean.

(It's watching the microformats community struggle with the problem of 
encoding machine data equivalents, for things like dates and telephone 
number types and measurements, that persuaded me HTML5 should include a 
generic machine data attribute, because it seems likely to me that the 
problem will be recurrent.)


--
Benjamin Hawkes-Lewis

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

[Calogero Alex Baldacchino]

Benjamin Hawkes-Lewis ha scritto:



After all, support for unknown attributes/elements has never been a
standard "de jure", but more of a quirk


Depends what you mean by "support" I guess.



I just mean that, as far as I know, there is no official standard 
requiring UAs to support (parse and expose through the DOM) attributes 
and elements which are not part of the HTML language but are found in 
text/html documents. Usually, browsers support them for robustness sake 
and/or backward compatibility with existing pages, but they might do it 
with significant differences (actually it happens for unknown elements 
but not for unknown attributes, but one shouldn't assume such common 
behavior might not change in the future, or that will be adopted by 
newer vendors (even if that might be a quite safe assumption), thus any 
hack to the language /for custom purposes and script elaboration/ should 
be done by the mean of existing attributes/elements instead of creating 
new ones (I mean, "data-rdfa-about" might be a bit safer than just 
"about" to use a conservative approach based on the assumption "I know 
what happens today, not what will happen tomorrow") -- before data-* it 
was possible through the class attribute, now also data-* can be used 
for custom hacks)



I really don't see the problem if a *custom* convention became widely
accepted and reused by other people


Then you I think you don't agree with the fundamental design principle 
of the "data-*" attribute. The theory is that extensions to HTML 
benefit from going through a community process like WHATWG or W3C, and 
blessing extension points encourages people to circumvent that 
process, with the result that browsers have to support poorly designed 
features in order to have an interoperable web.




Yet it is *possible* to use data-* attributes to define a proper 
*private* convention by choosing names carefully in order to avoid 
clashes with other private conventions (for instance, a widget might 
need metadata to be put within the host page, and a careful choice of 
data-* names might avoid clashes with other metadata needed by other 
widgets or by the page itself). More people might find a certain 
convention useful and enough reusable for their purposes (because of 
non-clashing names), and the result would be a clearer "caw path" that 
community "cawboys" might follow to catch the free problem running away 
from standards.


The *only* difference with "data-rdfa-*" here would be that a higher 
number of authors/developers should agree with such a convention from 
the beginning, but only if they were interested in exchanging the same 
metadata with each others for their respective *custom* uses (through a 
custom script or plugin, either developed independently or shared). From 
this point of view, the only difference between "data-rdfa-about" and 
"about" - as used for the purposes of SearchMonkey - is that the former 
is immediately conforming to HTML5 spec and, thus, surely exposed 
through the DOM by every possible HTML5 compliant UA, as it happens for 
classes used by Microformats. I've never thought to any requirements for 
UAs not coming from a clearly traced "caw path", the same way there is 
no requirement for UAs not involved in SearchMonkey to support any kind 
of metadata - for the purposes of SearchMonkey itself.


Unless one thinks that everyone facing a problem not solved (at all or 
enough for his purposes) by an official standard should either create a 
private hack disregarding any possible hacks for similar problems he 
might have happened to find on the web, or start a new community process 
eventually without knowing if other people are facing the same problem, 
or a similar one, I really can't understand why a *custom* and 
*born-private* (eventually within a group of authors/developers) and 
then become a widely accepted convention should be a problem, as far as 
it is based on existing, standard features and doesn't require any 
additional support and results in a possible cawpath to be then 
standardized as needed. And I really don't understand why class="xyz" is 
a good hack whereas "data-some-thing" is not, assuming both are designed 
for and used by "caws opening a path" ( :-P )



I really can't get, right now, why it should be different, for instance,
from the case of a freely reusable widget using a custom data model
based on private data-* attributes inserted by people in thousands of
websites (the widget with relitive metadata, I mean), then liked by
other people and reused in different contexts (the same data model based
on data-*, now)


Reuse of "data-*" by DHTML widgets would not impose any additional 
requirements on user agents, so it would be fine from the perspective 
elaborated above. It wouldn't change the language by the back door.


Really? Is it so much different from the case of the pattern attribute 
(which addresses, at the UA and language level, a problem earlier solved 
by scripts -- 

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

[Henri Sivonen]

On Jan 11, 2009, at 18:52, Calogero Alex Baldacchino wrote:

However, actually it's the same for RDFa attributes, because they're  
not in the spec. From this point of view, introducing six new  
attributes, or resorting to an older one is not very different, thus  
(again) why RDFa and not eRDF?



eRDF is very different in not relying on attributes whose qname  
contains the substring "xmlns".


--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

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

[Charles McCathieNevile]

On Sat, 10 Jan 2009 06:41:10 +1100, Julian Reschke   
wrote:



Tab Atkins Jr. wrote:
*If* we want to support RDFa, why not add the attributes the way they  
are

already named???

 Because the issue is that we don't yet know if we want to support
RDFa.  That's the whole point of this thread.  Nobody's given a useful
problem statement yet, so we can't evaluate whether there's a problem
we need to solve, or how we should solve it.


For the record: I disagree with that. I have the impression that no  
matter how many problems are presented, the answer is going to be: "not  
that stone -- fetch me another stone".


There does appear to be some of this. I have no idea if that is just an  
impression or the truth. Hence my continued following of the thread.



Alex's suggestion, while officially against spec, has the benefit of
allowing RDFa supporters to sort out their use cases through
experience.  That's the back door into the spec, after all; you don't


If something that is against the spec is acceptable, then it's *much*  
easier to just use the already defined attributes. Better breaking the  
spec by using new attributes then abusing existing ones.


Indeed. I the data-* attributes had some reserved values, then one might  
expect people to invest in them on the scale that they have typically made  
RDF investments. But then there would be no need to change the attribute  
names at all (nor, for that matter, to put much effort into other  
attribute names following the design pattern. It just becomes another  
approach to namespaces with another centralisation process required). The  
question is what would convince the editors of the spec that there is in  
fact a use case for RDF in HTML which is what has led to the request to  
include RDFa (a form of RDF carefully designed to fit into HTML).


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

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

[Benjamin Hawkes-Lewis]

On 11/1/09 16:52, Calogero Alex Baldacchino wrote:


Well, that's a chance, of course, but that's *not* RDFa as specified by
W3C; for instance, @property is specified as accepting _only_ CURIEs


Good point; I hadn't spotted that.


It's the same with every possible existing custom (non-standard)
attributes and elements out there, since there is no standard for them,
and instead data-* has been created;


Emphatically, data-* has been created for private use data encoding 
(basically for scripting purposes) not as a replacement for the existing 
practices of adding new elements and attributes to HTML without going 
through W3C/WHATWG.


Existing custom attributes intended for use by scripts (e.g. "action" in 
Gmail and Yahoo! Mail), have a direct migration path open for them (i.e. 
to "data-action" or a HTML5-native feature). Proprietary attributes 
intended for use by user agents (e.g. "autocomplete"), on the other 
hand, must be adopted by HTML5 if they are not to be remain non-conforming.



it's also the same for accesskey,
actually, since it's not in current spec (whereas it was in HTML4).


I suspect the behavior for "accesskey" will ultimately be defined by the 
spec, whether or not it is made conforming.



After all, support for unknown attributes/elements has never been a
standard "de jure", but more of a quirk


Depends what you mean by "support" I guess.


I really don't see the problem if a *custom* convention became widely
accepted and reused by other people


Then you I think you don't agree with the fundamental design principle 
of the "data-*" attribute. The theory is that extensions to HTML benefit 
from going through a community process like WHATWG or W3C, and blessing 
extension points encourages people to circumvent that process, with the 
result that browsers have to support poorly designed features in order 
to have an interoperable web.



I really can't get, right now, why it should be different, for instance,
from the case of a freely reusable widget using a custom data model
based on private data-* attributes inserted by people in thousands of
websites (the widget with relitive metadata, I mean), then liked by
other people and reused in different contexts (the same data model based
on data-*, now)


Reuse of "data-*" by DHTML widgets would not impose any additional 
requirements on user agents, so it would be fine from the perspective 
elaborated above. It wouldn't change the language by the back door.


--
Benjamin Hawkes-Lewis

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

[Calogero Alex Baldacchino]

Benjamin Hawkes-Lewis ha scritto:

On 11/1/09 02:51, Calogero Alex Baldacchino wrote:

eRDF might be a working compromise, because it doesn't need any changes
to the spec


It's not possible to author conforming HTML5 that functions as eRDF 
since eRDF requires a 'profile' attribute, but HTML5 has removed the 
attribute.




I didn't noticed that before, thanks for the info :-)

However, actually it's the same for RDFa attributes, because they're not 
in the spec. From this point of view, introducing six new attributes, or 
resorting to an older one is not very different, thus (again) why RDFa 
and not eRDF? Or why not both? Or not also RDFa embedded in Atom 
embedded, in turn, in HTML (like SVG or MathML)? It seems to me, for 
instance, that at this stage SearchMonkey might be a reason to consider 
all of them.




; RDFa covers a wider range of RDF semantics, but requires

new attributes and also namespaces (a sort of hybrid beteween them might
avoid the need to bring namespaces - xmlns:* attributes - into html
serialization).


To avoid xmlns:* attributes, one could drop CURIEs in the text/html 
serialization and use markup like:



  http://dbpedia.org/resource/Albert_Einstein";>
...
  


instead of

http://dbpedia.org/";>
  
...
  


There's no data loss.



Well, that's a chance, of course, but that's *not* RDFa as specified by 
W3C; for instance, @property is specified as accepting _only_ CURIEs 
(whereas @about can accept also URIs - and eRDF allows curies, even if 
in a different format than what specified for RDFa and what is used for 
XML in general). That is, to do that not one, but _two_ specifications 
need to be changed, current HTML5 (which is a draft, thus  not a 
problem) and RDFa (which now is a Recommendation, thus, might it be more 
difficoult? should a different specification be derived?), unless we 
want that to be just an unofficial, yet widely accepted, convention - 
and I think that an unofficial convention is worth the others (any 
processors conforming to standard RDFa would need deep changes to cope 
with that - it doesn't work in Fuzzbot when CURIEs are expected, for 
instance). I'm the first to say that my suggestion was an ugly hack, but 
at least it would have been working and conformant without changing 
anything.



My suggestion was meant as a mean to test RDFa in HTML
documents without changing the spec (perhaps in conjunction with
data-xmlns-*, data-xmlns-prefixes="rdfa foaf " to "emulate"
namespaces - an ugly hack, I know, but at least would avoid changes to
html serialization, at least in a test phase) -- even if I think that
xml serialization should work better for such rdf metadata.


I really can't see anybody violating the spec in that way rather than 
violating the spec by just adding the RDFa attributes outright, --


Indeed, current specs are violated, and I was just considering a way to 
use RDFa without such violations before deciding if it's worth to be 
added to the spec, no more (and I don't want to push that hack anymore, 
just trying to point out my aim).


--especially given that there are already people publishing these 
attributes in text/html so the "namespace" has already been polluted 
and we already have services like SearchMonkey not only using these 
attributes but promoting them.


It seems to me that SearchMontky doesn't promote RDFa more than it 
promotes Microformats, eRDF and dataRSS (RDFa embedded in external Atom 
feeds). It's also a very recent feature, and I really can't guess which 
kind of RDF serialization is going to "win the battle" (that is, 
choosing one against the others *might* be a premature choice right now, 
as well as introducing all of them).


It may therefore already be problematic for a future version of HTML 
to use these attributes as extension points without breaking existing 
sites. The "test" is already in progress, for better or worse. HTML5 
conformance checkers don't have to bless this test, of course, any 
more than CSS validators have to give the all clear to vendor-specific 
properties.


It's the same with every possible existing custom (non-standard) 
attributes and elements out there, since there is no standard for them, 
and instead data-* has been created; it's also the same for accesskey, 
actually, since it's not in current spec (whereas it was in HTML4). 
After all, support for unknown attributes/elements has never been a 
standard "de jure", but more of a quirk, and there are no grants it will 
work fine in the future (as well as actually it doesn't work 
consistently for unknown elements cross-browsers -- there are strong 
differences between IE and other browsers with this respect).


Moreover, the use of such attributes /for the purposes of SearchMonkey/ 
is a very, very custom use case, since they're used just for server-side 
computations, thus no collaboration is required by other UAs; if 
browsers just ignored and dropped such attributes (as they do with 
unknown, proprietary CSS 

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

[Benjamin Hawkes-Lewis]

On 11/1/09 02:51, Calogero Alex Baldacchino wrote:

eRDF might be a working compromise, because it doesn't need any changes
to the spec


It's not possible to author conforming HTML5 that functions as eRDF 
since eRDF requires a 'profile' attribute, but HTML5 has removed the 
attribute.


http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml

; RDFa covers a wider range of RDF semantics, but requires

new attributes and also namespaces (a sort of hybrid beteween them might
avoid the need to bring namespaces - xmlns:* attributes - into html
serialization).


To avoid xmlns:* attributes, one could drop CURIEs in the text/html 
serialization and use markup like:



  http://dbpedia.org/resource/Albert_Einstein";>
...
  


instead of

http://dbpedia.org/";>
  
...
  


There's no data loss.


My suggestion was meant as a mean to test RDFa in HTML
documents without changing the spec (perhaps in conjunction with
data-xmlns-*, data-xmlns-prefixes="rdfa foaf " to "emulate"
namespaces - an ugly hack, I know, but at least would avoid changes to
html serialization, at least in a test phase) -- even if I think that
xml serialization should work better for such rdf metadata.


I really can't see anybody violating the spec in that way rather than 
violating the spec by just adding the RDFa attributes outright, 
especially given that there are already people publishing these 
attributes in text/html so the "namespace" has already been polluted and 
we already have services like SearchMonkey not only using these 
attributes but promoting them. It may therefore already be problematic 
for a future version of HTML to use these attributes as extension points 
without breaking existing sites. The "test" is already in progress, for 
better or worse. HTML5 conformance checkers don't have to bless this 
test, of course, any more than CSS validators have to give the all clear 
to vendor-specific properties.


Moreover, the damage done by immediately breaking the principle that 
data-* should be for private use only and turning it into a distributed 
extension point may be worse than the alternatives.


--
Benjamin Hawkes-Lewis

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

[Calogero Alex Baldacchino]

Kornel Lesiński ha scritto:

On 09.01.2009, at 01:54, 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


One can also use . I 
don't see why RDF metadata must be in the HTML document. It could be 
in a separated file, maybe embedded in RSS/Atom feeds (RSS1.0 is 
pretty close already).


Websites that have a lot of useful data to share usually keep it in a 
database, and this allows them to easily generate RDF as separate 
documents without risk of getting out of sync with the HTML version.




In principle, I agree (also, Atom 1.0 embedding RDFa as dataRSS is the 
base of SearchMonkey). But if people feel the need to embed metadata in 
their documents and to use them as a distributed database, well, let's 
give them a chance to do so. :-P


eRDF might be a working compromise, because it doesn't need any changes 
to the spec; RDFa covers a wider range of RDF semantics, but requires 
new attributes and also namespaces (a sort of hybrid beteween them might 
avoid the need to bring namespaces - xmlns:* attributes - into html 
serialization). My suggestion was meant as a mean to test RDFa in HTML 
documents without changing the spec (perhaps in conjunction with 
data-xmlns-*, data-xmlns-prefixes="rdfa foaf " to "emulate" 
namespaces - an ugly hack, I know, but at least would avoid changes to 
html serialization, at least in a test phase) -- even if I think that 
xml serialization should work better for such rdf metadata.


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:
Con Danone Activia, puoi vincere cellulari Nokia e Macbook Air. Scopri come
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8549&d=11-1

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

[Kornel Lesiński]

On 09.01.2009, at 01:54, 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


One can also use . I  
don't see why RDF metadata must be in the HTML document. It could be  
in a separated file, maybe embedded in RSS/Atom feeds (RSS1.0 is  
pretty close already).


Websites that have a lot of useful data to share usually keep it in a  
database, and this allows them to easily generate RDF as separate  
documents without risk of getting out of sync with the HTML version.


IMHO even RDFa metadata is invisible, and errors in RDFa wouldn't be  
much easier to spot than erorrs in external RDF files, e.g.:


http://xmlns.com/foaf/1.0/";
xmlns:atom="http://purl.org/atom/ns#";>
 
   On 10 Jan 2009,
   http://joe.example.com";>Joe Bloggs wrote:
 

--
regards, Kornel

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

[Calogero Alex Baldacchino]

Toby A Inkster ha scritto:


It should be noted in this case that RDFa also allows natural language 
parsers to be made more useful. By looking at the RDFa which marks up 
the author's name and website, they may be able to determine that the 
comment has been written by someone other than the page's main author, 
and thus not afford it the same level of trust granted to the rest of 
the page. So the natural language processing can benefit from RDFa.




That's true only if one can assume metadata are trustful, but they are 
only if they can be under a strict control, that is on a small-scale 
application. On a wider scale, one needs to make the opposite 
assumption, because it would or might be more common to find fake 
metadata with "honest" content (the prose of an advertisement does not 
lie, but related metadata can tell it's a different think to cheat a 
metadata-based UA), either because a site author can be a party to the 
spammer, or because authors can mess up metadata (yeah, they can mess up 
html code too, but that's either not a problem, because a UA can present 
the content as well, or it is but it might damage the author more than 
it may harm the user). If metadata are created/used for external 
consumption, they can be just ignored by authors, who instead may just 
copy&paste code or reuse templates in different contexts, without being 
able to set proper metadata for the new content. Thus UAs can't rely on 
metadata /in general/, while they might /in some/, small-scale scenarios.


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:
Con Danone Activia, puoi vincere cellulari Nokia e Macbook Air. Scopri come
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8547&d=10-1

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

[Toby A Inkster]

Dan Brickley wrote:


While I'm unsure about the "commercial relationship" clause quite
capturing what's needed, the basic idea seems sound. Is there any
provision (or plans) for applying this notion to entire blocks of
markup, rather than just to simple hyperlinks? This would be rather
useful for distinguishing embedded metadata that comes from the page
author from that included from blog comments or similar.


While that might be useful for natural language processing, for RDFa  
it is actually completely unneeded. The syntax of RDFa allows for  
blocks of markup to be made "invisible" by making an ancestor node  
into an XMLLiteral.


For example, a comment might be marked up as:

http://xmlns.com/foaf/0.1/";
xmlns:atom="http://bblfish.net/work/atom-owl/2006-06-06/#";>
  
On 10 Jan 2009,
http://joe.example.com";>Joe Bloggs wrote:
  
  

  

  


The RDFa processing instructions say that as the blockquote doesn't  
have an explicit datatype set, it is to be treated entirely as a  
string literal (if it doesn't have any child elements) or an XML  
literal (if it does), and that parsers must not look inside it for  
triples. Thus spammers can't use the comment form for stuffing  
triples into the page.


It should be noted in this case that RDFa also allows natural  
language parsers to be made more useful. By looking at the RDFa which  
marks up the author's name and website, they may be able to determine  
that the comment has been written by someone other than the page's  
main author, and thus not afford it the same level of trust granted  
to the rest of the page. So the natural language processing can  
benefit from RDFa.


--
Toby A Inkster

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

[Calogero Alex Baldacchino]

Ben Adida ha scritto:

Ian Hickson wrote:
  
We have to make sure that whatever we specify in HTML5 actually is going 
to be useful for the purpose it is intended for. If a feature intended for 
wide-scale automated data extraction is especially susceptible to spamming 
attacks, then it is unlikely to be useful for wide-scale automated data 
extraction.



It's no more susceptible to spam than existing HTML, as per my previous
response.

  


Perhaps this is why general purpose search engines do not rely 
(entirely) on metadata and markup semantics to classify content, nor 
does Yahoo with SearchMonkey. SearchMonkey documentation points out that 
metadata never affects page ranks, nor is semantics interpreted for any 
purpose; metadata only affects additional informations presented to the 
user at the user will, and if the user chose to get informations of a 
certain kind (gathered by a certain data service), thus spammy metadata 
can be thought as circumscribed in this case, they might corrupt 
SearchMonkey additional data, but not the user's overall experience with 
the search engine. From this point of view, SearchMonkey is some kind of 
wide-range but small-scale use case (with respect to each tool and each 
site the user might enable), because the user can easily choose which 
sources to trust (e.g. which data services to use, or which sites to 
look for additional infos), and in any case he can get enough infos 
without metadata.


On the other hand, a client UA implementing a feature entirely based on 
metadata couldn't easily circumscribe abused metadata and bring valid 
informations to the user attention, nor could the average user take 
easily trusted and spammy sites apart, because he wouldn't understand 
the problem (and a site with spammy metadata might still contain 
informations users were interested in previously, or in a different 
context), whereas in SearchMonkey the average user would notice 
something doesn't work in enhanced results, but he'd also get the basic 
infos he was looking for. Thus there are different requirements to be 
taken into account for different scenarios (SearchMonkey and client UA 
are such different scenarios)


Moreover, SearchMonkey is a kind of centralised service based on 
distributed metadata, it doesn't need collaboration by any other UA 
(that is, it doesn't need support for metadata in other software) by 
default (whereas it allows custom data services to autonomously extract 
metadata, but always for the purposes of SearchMonkey), it only requires 
that web sites adhering to the project (or just willing to provide 
additional infos) embed some kind of metadata only for the purpose of 
making them available to SearchMonkey services, or at least that authors 
create appropriate metadata and send them to Yahoo (in the form of 
dataRSS embedded in a Atom document). That is, SearchMonkey seems to me 
a clear example of a use case for metadata not requiring any changes to 
html5 spec, since any kind of supported metadata are used by 
SearchMonkey as if they were custom, private metadata; whatever happens 
to such metadata client-side, even if they're just stripped by a 
browser, doesn't really matter.


Furthermore, SearchMonkey supports several kinds of metadata, not only 
RDFa, but also eRDF, microformats and dataRSS external to the document. 
So, why should SearchMonkey be the reason to introduce explicit support 
to RDFa and not also for eRDF, which doesn't require new attributes, but 
just a parser? One might think one solution is better than the other, 
and this might be true in theory, but what really counts is what people 
do find easier to use, and this might be determined by experience with 
SearchMonkey (that is, let's see what people use more often, then decide 
what's more needed).


Moreover, RDFa is thought for xhtml, thus it can't be introduced in html 
serialization just by defining a few new attributes: a processor would 
or might need some knowledge over /namespaces/, thus the whole "family" 
of *xmlns* attributes (with and without prefixes) should be specified 
for use with the html serialization, unless an alternative mechanism, 
similar to the one chosen for eRDF, were defined, and maybe such would 
result in a new, hybrid mechanism (stitching together pieces from eRDF 
and RDFa). Buf if we introduce xmlns and xmlns: into html 
serialization, why not also prefixed attributes? That is, can RDFa be 
introduced into html serialization "as is", without resorting to the 
whole xml extensibility? This should be taken into account as well, 
because just adding new attributes to the language might work fine for 
xml-serialized documents, but might not for html-serialized ones. This 
means RDFa support might be more difficult than it may seem at first 
glance, whereas it might not be needed for custom and/or small scale use 
cases (and I think SearchMonkey is one such case).


Nobody is suggesting that user agents derive any behavior from , 

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

[Dan Brickley]

On 10/1/09 00:37, Ian Hickson wrote:

On Fri, 9 Jan 2009, Ben Adida wrote:

Is inherent resistance to spam a condition (even a consideration) for
HTML5?


We have to make sure that whatever we specify in HTML5 actually is going
to be useful for the purpose it is intended for. If a feature intended for
wide-scale automated data extraction is especially susceptible to spamming
attacks, then it is unlikely to be useful for wide-scale automated data
extraction.


I've been looking at such concerns a bit for RDFa. One issue (shared 
with HTML in general I think) is user-supplied content, eg. blog 
comments and 'rel=nofollow' scenarios).  Is there any way in HTML5 to 
indicate that a whole chunk of Web page is from an (in some 
to-be-defined sense) untrusted source?


I see http://www.whatwg.org/specs/web-apps/current-work/#link-type-nofollow

"The nofollow keyword indicates that the link is not endorsed by the 
original author or publisher of the page, or that the link to the 
referenced document was included primarily because of a commercial 
relationship between people affiliated with the two pages."


While I'm unsure about the "commercial relationship" clause quite 
capturing what's needed, the basic idea seems sound. Is there any 
provision (or plans) for applying this notion to entire blocks of 
markup, rather than just to simple hyperlinks? This would be rather 
useful for distinguishing embedded metadata that comes from the page 
author from that included from blog comments or similar.


Thanks for any pointers,

cheers,

Dan

--
http://danbri.org/

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

[Ian Hickson]

On Fri, 9 Jan 2009, Ben Adida wrote:
> 
> SearchMonkey, which you continue to ignore, is an important use case.

When did I ignore it? I discussed it in depth in my e-mail in December, 
listing a number of use cases and requirements that I thought it 
demonstrated, and asking if there were any others I'd missed.


> Before I invest significant time in responding to your barrage of 
> questions, I'm looking for a hint of objective evaluation on your end.

All I'm trying to do is evaluate things objectively. I don't know how much 
more I can "hint" towards this.

Indeed, every question I asked in the aforementioned e-mail had no reason 
_other_ than to enable me to objectively evaluate the proposals.


> > Note that search engines aren't the problem here
> 
> Actually, we were discussing SearchMonkey, so I think it's very much the 
> context for this sub-thread.

I meant that search engines weren't the problem when it came to spam. 
Search engines can deal with distributed spam. The techniques developed to 
combat distributed spam don't really work on the scale of a single user's 
machine and browser.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

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

[Ben Adida]

Ian Hickson wrote:
> We have to make sure that whatever we specify in HTML5 actually is going 
> to be useful for the purpose it is intended for. If a feature intended for 
> wide-scale automated data extraction is especially susceptible to spamming 
> attacks, then it is unlikely to be useful for wide-scale automated data 
> extraction.

It's no more susceptible to spam than existing HTML, as per my previous
response.

> Nobody is suggesting that user agents derive any behavior from , so 
> it doesn't matter if  is spammed or not.

And RDFa does not mandate any specific behavior, only the ability to
express structure. The power lies in products like SearchMonkey that
make use of this structure with innovative applications.

Can one imagine tools that make poor use of this structured data so that
they incentivize spam? Absolutely. Is this the bar for HTML5? If bad or
poorly conceived applications can be imagined, then it's not in the
standard?

> It is less likely for a user to intentionally visit a 
> spammy page than for a user to visit a page that happens to contain spammy 
> content embedded within it (e.g. in blog comments).

You've done plenty of web security work, and I suspect you know well
that spammy RDFa is the least in a large set of problems that come with
accepting arbitrary markup in blog comments. This is a strawman.

> However, browsers don't do this kind of processing -- 
> indeed, this kind of processing appears to be exactly what RDFa proponents 
> are trying to enable (though to what end, I'm still trying to find out, 
> since nobody has actually replied to all the questions I asked yet [1]).

While client-side processing is indeed an important use case (Ubiquity,
Fuzzbot, etc...), it's not the only one. SearchMonkey, which you
continue to ignore, is an important use case.

Before I invest significant time in responding to your barrage of
questions, I'm looking for a hint of objective evaluation on your end. I
thought I saw an opportunity for productive discussion based on common
ground with SearchMonkey, but this has led again into a new and
close-to-bogus reason for blocking consideration of RDFa.

> Note that search engines aren't the problem here

Actually, we were discussing SearchMonkey, so I think it's very much the
context for this sub-thread. You continue to ignore SearchMonkey, for
reasons which, as I've pointed out in a response earlier today, are
factually incorrect.

-Ben

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

[Ben Adida]

Tab Atkins Jr. wrote:
> To answer your specific question,  is under the control of the
> site author, and search engines already have elaborate methods to tell
> a spammy site from a hammy one, thus downranking them.

And RDFa is also entirely under the control of the site author.

> On the other hand, the hypothetical attack scenario I outlined was
> about metadata that could be added to the page by external parties.

I thought your attack concerned both author markup and commenter markup.
But it seems we agree on author markup: no additional risk there.

So on to commenter markup.

Most blogging software already white-lists the HTML elements and
attributes they allow, otherwise they are easily hacked with XSS. This
means that, by default, most blogging software will strip RDFa from
comments, which is exactly the right approach, since comments should not
have authority over the structured data of the page.

-Ben

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

[Ian Hickson]

On Fri, 9 Jan 2009, Ben Adida wrote:
> 
> Is inherent resistance to spam a condition (even a consideration) for 
> HTML5?

We have to make sure that whatever we specify in HTML5 actually is going 
to be useful for the purpose it is intended for. If a feature intended for 
wide-scale automated data extraction is especially susceptible to spamming 
attacks, then it is unlikely to be useful for wide-scale automated data 
extraction.


> If so, where is the concern around , which is clearly featured in 
> search engine results?

Nobody is suggesting that user agents derive any behavior from , so 
it doesn't matter if  is spammed or not. The only effect would be 
some spam in the user's session history. Furthermore,  is page- 
wide, meaning that the actual page author would have to spam the page for 
it to be spamed. It is less likely for a user to intentionally visit a 
spammy page than for a user to visit a page that happens to contain spammy 
content embedded within it (e.g. in blog comments).

If browsers were expected to crawl all pages for all links and then 
populate the browser's interface with the most popular links, then one 
would quickly expect everyone's browsers to be advertising Viagra, porn 
sites, and the like. However, browsers don't do this kind of processing -- 
indeed, this kind of processing appears to be exactly what RDFa proponents 
are trying to enable (though to what end, I'm still trying to find out, 
since nobody has actually replied to all the questions I asked yet [1]).

Note that search engines aren't the problem here -- large operations like 
search engines are quite capable of running the massive processing 
required to filter spam. The problem is automated processing on the 
client, where those resources aren't available.

[1] 
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-December/018023.html

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

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

[Tab Atkins Jr.]

On Fri, Jan 9, 2009 at 5:13 PM, Ben Adida  wrote:
> Tab Atkins Jr. wrote:
>> This brings up different issues, however.
>
> Is inherent resistance to spam a condition (even a consideration) for
> HTML5? If so, where is the concern around , which is clearly
> featured in search engine results?

Well, it's something that we probably want to keep in mind, because
it's so relevant for the success of any such proposal.  I wouldn't
want to lend support to a feature that turned out to be immediately
useless due to spam.  Lot of wasted effort on the WG's, Ian's, and
possibly browser developer's part.

To answer your specific question,  is under the control of the
site author, and search engines already have elaborate methods to tell
a spammy site from a hammy one, thus downranking them.

On the other hand, the hypothetical attack scenario I outlined was
about metadata that could be added to the page by external parties.

If we were today discussing adding  to HTML5 to help search
engines provide a short summary of a page, and part of the proposal
might allow blog commenters to change the title of pages on a whim,
I'd certainly be equally concerned.  ^_^

~TJ

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

[Ben Adida]

Tab Atkins Jr. wrote:
> This brings up different issues, however.

Is inherent resistance to spam a condition (even a consideration) for
HTML5? If so, where is the concern around , which is clearly
featured in search engine results?

-Ben

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

[Tab Atkins Jr.]

On Fri, Jan 9, 2009 at 3:22 PM, Ben Adida  wrote:
> Tab Atkins Jr. wrote:
>> However, Ian has a point in his first paragraph.  SearchMonkey does
>> *not* do auto-discovery; it relies entirely on site owners telling it
>> precisely what data to extract, where it's allowed to extract it from,
>> and how to present it.
>
> That's incorrect.
>
> You can build a SearchMonkey infobar that is set to function on all URLs
> (just use "*" in your URL field.)
>
> For example, the Creative Commons SearchMonkey application:
>
> http://gallery.search.yahoo.com/application?smid=kVf.s
>
> (currently broken because of a recent change in the SearchMonkey PHP API
> that we need to address, so here's a photo:
>
> http://www.flickr.com/photos/ysearchblog/2869419185/
> )
>
> By adding the CC RDFa markup to your page, it will show up with the
> infobar in Yahoo searches.

Ah, hadn't considered a net-wide SearchMonkey script.  Interesting.

This brings up different issues, however.  Something I see
immediately: Say I'm a scammer.  I know that the CC SearchMonkey app
is in wide use (pretend, here).  I start putting CC-RDF data in spam
blog comments, with my own spammy stuff in the relevant fields.  Now
people don't even have to click on the blog link in the search results
and read my obviously spammy comment to be introduced to my offers for
discount Viagra!  They'll just see a little CC bar, click on it to
have it open in-place, and there I am.  I could even hide my link in
legitimate license data, so that people only hit my malicious site
when they click the link to see more information about the license.

Issues like these make wide-scale auto-trusted use of metadata
difficult.  It also makes me more reluctant to want it in the spec
yet.  I'd rather see the community work out these problems first.  It
may be that there's a relatively simple solution.  It may be that the
crawlers can reliably distinguish between ham and spam CC data.  But
then, it may be that there *is* no good solution enabling us to use
this approach, and this kind of metadata on arbitrary sites just can't
be trusted.

I, personally, don't know the answer to this yet.  I suspect that you
don't, either; if the arbitrary-site CC infobar works at all, it's
because few people *use* CC RDF yet, and so it's still limited to a
community with implicit trust.

> So site-specific microformats are clearly less powerful. And
> vocabulary-specific microformats, while useful, are also not as useful
> here (consider a SearchMonkey application that picks up CC-licensed
> items, be they video, audio, books, scientific data, etc... Different
> microformats = development hell.)

Indeed, they are less powerful.  As I explored above, though, too much
power can be damning. It may be that the site-specific little-m
microformat (or something equivalent, allowing a developer to extract
metadata through actively targeting site structure) is powerful enough
to be useful, but weak enough to *remain* useful in the face of abuse.

(Also, I know CC is sort of the darling of the RDFa community, but
there's significant enough debate over in-band vs out-of-band
licensing info, etc. that detracts from the core issues we're trying
to discuss here that it's probably not the best example to use.)

> Have you read the RDFa Primer?
> http://www.w3.org/TR/xhtml-rdfa-primer/
>
> It describes (pre-SearchMonkey) the kind of applications that can be
> built with RDFa. SearchMonkey is an ideal example, but it's by no means
> the only one.

Yup; I was an active participant in this discussion when it started
last August.  The example applications discussed in the paper,
unfortunately, are precisely the kind where trusting metadata is
likely a *bad* idea.  For example, finding reviews of shows produced
by friends of Alice, using foaf and hreview, is rife with opportunity
for spamming.  SearchMonkey seems to avoid this for the most part;
when designing applications for particular URLs, at least, you are
relying on relatively trustworthy data, not arbitrary data scattered
across the web.  Perhaps something similar has application within
trusted networks, but in that case it comprises a completely different
use case than what SearchMonkey hits, with possibly different
requirements.

~TJ

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

[Calogero Alex Baldacchino]

Ben Adida ha scritto:

Tab Atkins Jr. wrote:
  

Actually, SearchMonkey is an excellent use case, and provides a
problem statement.



I'm surprised, but very happily so, that you agree.

My confusion stems from the fact that Ian clearly mentioned SearchMonkey
in his email a few days ago, then proceeded to say it wasn't a good use
case.

-Ben

  


It seems to me that's a very custom use case - though requiring metadata 
to be embedded in a big number of pages, but that's an optional 
requirement, because search results don't rely only on metadata -  since 
metadata are used as an optional source for informations by the server 
and don't require any collaboration by other kinds of UA (excluding, at 
most, some custom data services - whereas, for instance, a search engine 
using the mark element to highlight a keyword would require a client UA 
to understand and style it properly -- I expect it not to be working on 
IE6, for instance, because IEx browsers deal with unknown elements as if 
their content where misplaced). That is, Yahoo might develop his own 
data model and work fine with sites implementing it; perhaps RDF(a) was 
chosen because they might think RDF is a natural way to model data which 
are sparse in a web page (and re-mapping microformats on RDF might 
result in an easier implementation); anyway, in this case the only UA 
needing to understand RDFa, in this case, is SearchMonkey itself, thus a 
client browser might just drop RDFa attributes without breaking 
SearchMonkey functionalities -- at least, this is my first impression.


Furthermore, it's a very recent (yet potentially interesting) 
application, so why not to wait and see how it grows, if the opt-in 
mechanism will effectively prevent spam (e.g. spammers might model data 
basing on widely diffused vocabularies and data services, and find a way 
to make such data available in searches when users asks for additional 
infos, for instance through an ad within a page of an accomplice author, 
or exploiting some kind of errors in authors' selection of URLs to be 
crawled for metadata, or the alike), or just which model become the most 
used among RDFa, eRDF, Microformats, Atom embedding dataRSS and whatever 
else Yahoo might decide to support, before choosing to include one or 
the other into html5 specification (or to include each one because 
equally diffused)? Moreover, it seems that some xml processing is needed 
to create a custom data service, thus it might be natural to use xhtml 
(possibly along with namespaces and prefixed attributes) to provide 
metadata to such a data service, which might rely on an xml parser 
instead of implementing one from scratch (and html parser might not 
support namespaces for the purpose to expose them through DOM 
interfaces, as I understand html serialization) -- the use of prefixed 
RDFa attributes, or perhaps even unprefixed ones, within an 
xml-serialized document, shouldn't require a formalization in html5 
spec, as far as there is no strict requirement for UAs to support RDF 
processing - as it is for the purposes of SearchMonkey and its related 
data services.


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:
Con Danone Activia, puoi vincere cellulari Nokia e Macbook Air. Scopri come
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8551&d=9-1

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

[Ben Adida]

Tab Atkins Jr. wrote:
> However, Ian has a point in his first paragraph.  SearchMonkey does
> *not* do auto-discovery; it relies entirely on site owners telling it
> precisely what data to extract, where it's allowed to extract it from,
> and how to present it.

That's incorrect.

You can build a SearchMonkey infobar that is set to function on all URLs
(just use "*" in your URL field.)

For example, the Creative Commons SearchMonkey application:

http://gallery.search.yahoo.com/application?smid=kVf.s

(currently broken because of a recent change in the SearchMonkey PHP API
that we need to address, so here's a photo:

http://www.flickr.com/photos/ysearchblog/2869419185/
)

By adding the CC RDFa markup to your page, it will show up with the
infobar in Yahoo searches.

So site-specific microformats are clearly less powerful. And
vocabulary-specific microformats, while useful, are also not as useful
here (consider a SearchMonkey application that picks up CC-licensed
items, be they video, audio, books, scientific data, etc... Different
microformats = development hell.)

Have you read the RDFa Primer?
http://www.w3.org/TR/xhtml-rdfa-primer/

It describes (pre-SearchMonkey) the kind of applications that can be
built with RDFa. SearchMonkey is an ideal example, but it's by no means
the only one.

-Ben

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

[Tab Atkins Jr.]

On Fri, Jan 9, 2009 at 2:17 PM, Ben Adida  wrote:
> Tab Atkins Jr. wrote:
>> Actually, SearchMonkey is an excellent use case, and provides a
>> problem statement.
>
> I'm surprised, but very happily so, that you agree.
>
> My confusion stems from the fact that Ian clearly mentioned SearchMonkey
> in his email a few days ago, then proceeded to say it wasn't a good use
> case.

I apologize; looking back into my archives, it appears there was an
entire subthread specifically about SearchMonkey!  Also, Ian did
indeed mention it in his first email in this thread.  He actually gave
it more attention than any other single use-case, though.  I'll quote
the relevant part:

> On Tue, 26 Aug 2008, Ben Adida wrote:
> >
> > Here's one example. This is not the only way that RDFa can be helpful,
> > but it should help make things more concrete:
> >
> >   http://developer.yahoo.com/searchmonkey/
> >
> > Using semantic markup in HTML (microformats and, soon, RDFa), you, as a
> > publisher, can choose to surface more relevant information straight into
> > Yahoo search results.
>
> This doesn't seem to require RDFa or any generic data syntax at all. Since
> the system is site-specific anyway (you have to list the URLs you wish to
> act against), the same kind of mechanism could be done by just extracting
> the data straight out of the page. This would have the advantage of
> working with any Web page without requiring the page to be written using a
> particular syntax.
>
> However, if SearchMonkey is an example of a use case, then we should
> determine the requirements for this feature. It seems, based on reading
> the documentation, that it basically boils down to:
>
>  * Pages should be able to expose nested lists of name-value pairs on a
>   page-by-page basis.
>
>  * It should be possible to define globally-unique names, but the syntax
>   should be optimised for a set of predefined vocabularies.
>
>  * Adding this data to a page should be easy.
>
>  * The syntax for adding this data should encourage the data to remain
>   accurate when the page is changed.
>
>  * The syntax should be resilient to intentional copy-and-paste authoring:
>   people copying data into the page from a page that already has data
>   should not have to know about any declarations far from the data.
>
>  * The syntax should be resilient to unintentional copy-and-paste
>   authoring: people copying markup from the page who do not know about
>   these features should not inadvertently mark up their page with
>   inapplicable data.
>
> Are there any other requirements that we can derive from SearchMonkey?

I agree with Ian in that SearchMonkey is not *necessarily* speaking in
favor of RDFa; that may be what caused you to think he was dismissing
it.  In truth, Ian is merely trying to take current examples of RDFa
use and distill them into their essence.  (To grab my previous
example, it is similar to seeing what all the various rounded-corners
hacks were doing, without necessarily implying that the final solution
will be anything like them.  It's important to distill the actual
problems that users are solving from the details of particular
solutions they are using.)

Like I said, I think SearchMonkey sounds absolutely awesome, and
genuinely useful on a level I haven't yet seen any apps of similar
nature reach.  I'm exclusively a Google user, but that's something I'd
love to have ported over.  It's similar in nature to IE8's
Accelerators, in that it's an opt-in application for users that
reduces clicks to get to information they actively decide they want.

However, Ian has a point in his first paragraph.  SearchMonkey does
*not* do auto-discovery; it relies entirely on site owners telling it
precisely what data to extract, where it's allowed to extract it from,
and how to present it.  It is likely that this can be done entirely
within the confines of current html, and the fact that SearchMonkey
can use Microformats suggests that this is true.  A possible approach
is a site-owner producing an ad-hoc microformat (little m) that the
crawler can match against pages and index the information of, and then
offer to the SearchMonkey application for presentation as the
developer wills.  This would require specified parsing rules for such
things (which, as mentioned in an earlier email, the big-m
Microformats community is working on).

The question is, would this be sufficient?  Are other approaches
easier for authors?  RDFa, as noted, already has a specified parsing
model.  Does this make it easier for authors to design data templates?
 Easier to communicate templates to a crawler?  Easier to deploy in a
site?  Easier to parse for a crawler?

SearchMonkey makes mention of developers producing SearchMonkey apps
without the explicit permission of site owners.  This use would almost
certainly be better served with a looser data discovery model than
RDFa, so that a site owner doesn't have to explicitly comply in order
for others to extract useful data from their 

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

[Ben Adida]

Tab Atkins Jr. wrote:
> Actually, SearchMonkey is an excellent use case, and provides a
> problem statement.

I'm surprised, but very happily so, that you agree.

My confusion stems from the fact that Ian clearly mentioned SearchMonkey
in his email a few days ago, then proceeded to say it wasn't a good use
case.

-Ben

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

[Tab Atkins Jr.]

On Fri, Jan 9, 2009 at 1:48 PM, Ben Adida  wrote:
> Julian Reschke wrote:
>>> Because the issue is that we don't yet know if we want to support
>>> RDFa.  That's the whole point of this thread.  Nobody's given a useful
>>> problem statement yet, so we can't evaluate whether there's a problem
>>> we need to solve, or how we should solve it.
>>
>> For the record: I disagree with that. I have the impression that no
>> matter how many problems are presented, the answer is going to be: "not
>> that stone -- fetch me another stone".
>
> For the record: I completely agree with Julian. This is why I haven't
> jumped into this thread yet again.
>
> The key piece of evidence here is SearchMonkey, a product by Yahoo that
> specifically uses RDFa. Even its microformat support funnels everything
> to an RDF-like metadata approach. With thousands of application
> developers and some concrete examples that specifically use RDFa (the
> Creative Commons application being one of them), the message from many
> on this list remains "not good enough."
>
> I'm not sure where the bar is, but it seems far from objective.

Actually, SearchMonkey is an excellent use case, and provides a
problem statement.

Problem
===

Site owners want a way to provide enhanced search results to the
engines, so that an entry in the search results page is more than just
a bare link and snippet of text, and provides additional resources for
users straight on the search page without them having to click into
the page and discover those resources themselves.

For example (taken directly from the SearchMonkey docs), yelp.com may
want to provide additional information on restaurants they have
reviews for, pushing info on price, rating, and phone number directly
into the search results, along with links straight to their reviews or
photos of the restaurant.

Different sites will have vastly different needs and requirements in
this regard, preventing natural discovery by crawlers from being
effective.

(SearchMonkey itself relies on the user registering an add-in on their
Yahoo account, so spammers can't exploit this - the user has to
proactively decide they want additional information from a site to
show up in their results, then they click a link and the rest is
automagical.)


That really wasn't hard.  I'd never seen SearchMonkey before (it's
possible it was mentioned, but I know that it was never explicitly
described), but it's a really sweet app that helps both authors and
users.  That's a check mark in my book.

~TJ

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

[Calogero Alex Baldacchino]

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 

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

[Ben Adida]

Julian Reschke wrote:
>> Because the issue is that we don't yet know if we want to support
>> RDFa.  That's the whole point of this thread.  Nobody's given a useful
>> problem statement yet, so we can't evaluate whether there's a problem
>> we need to solve, or how we should solve it.
> 
> For the record: I disagree with that. I have the impression that no
> matter how many problems are presented, the answer is going to be: "not
> that stone -- fetch me another stone".

For the record: I completely agree with Julian. This is why I haven't
jumped into this thread yet again.

The key piece of evidence here is SearchMonkey, a product by Yahoo that
specifically uses RDFa. Even its microformat support funnels everything
to an RDF-like metadata approach. With thousands of application
developers and some concrete examples that specifically use RDFa (the
Creative Commons application being one of them), the message from many
on this list remains "not good enough."

I'm not sure where the bar is, but it seems far from objective.

-Ben

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

[Julian Reschke]

Tab Atkins Jr. wrote:

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


Because the issue is that we don't yet know if we want to support
RDFa.  That's the whole point of this thread.  Nobody's given a useful
problem statement yet, so we can't evaluate whether there's a problem
we need to solve, or how we should solve it.


For the record: I disagree with that. I have the impression that no 
matter how many problems are presented, the answer is going to be: "not 
that stone -- fetch me another stone".



Alex's suggestion, while officially against spec, has the benefit of
allowing RDFa supporters to sort out their use cases through
experience.  That's the back door into the spec, after all; you don't


If something that is against the spec is acceptable, then it's *much* 
easier to just use the already defined attributes. Better breaking the 
spec by using new attributes then abusing existing ones.


> ...

BR, Julian

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

[Tab Atkins Jr.]

On Fri, Jan 9, 2009 at 5:46 AM, Julian Reschke  wrote:
> 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-*.
>
> *If* we want to support RDFa, why not add the attributes the way they are
> already named???

Because the issue is that we don't yet know if we want to support
RDFa.  That's the whole point of this thread.  Nobody's given a useful
problem statement yet, so we can't evaluate whether there's a problem
we need to solve, or how we should solve it.

Alex's suggestion, while officially against spec, has the benefit of
allowing RDFa supporters to sort out their use cases through
experience.  That's the back door into the spec, after all; you don't
have to do as much work to formulate a problem statement if you can
point to large amounts of people hacking around a current lack, as
that's a pretty strong indicator that there *is* a problem needing to
be solved.  As an added benefit, the fact that there's already
multiple independent attempts at a solution gives us a wide pool of
experience to draw from in formulating the actual spec, so as to make
the use as easy as possible for authors.

(An example that comes to mind in this regard is rounded corners.
Usually you have to break semantics and put in junk elements to get
rounded corners on a flexible box.  This became so common that the
question of whether or not rounded corners were significant enough to
be added in CSS answered itself - people are trying hard to hack the
support in, so it's clearly something they want, and thus it's
worthwhile to spec a method (the border-radius property) to give them
it.  It solves a problem that authors, through their actions, made
extremely clear, and it does so in a way that is enormously simpler
99% of the time.  Win-win.)

~Tj

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

[Julian Reschke]

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

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



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

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

[Calogero Alex Baldacchino]

Charles McCathieNevile ha scritto:
On Mon, 05 Jan 2009 01:21:33 +1100, Henri Sivonen  
wrote:

On Jan 2, 2009, at 14:01, Benjamin Hawkes-Lewis wrote:

On 2/1/09 10:38, Henri Sivonen wrote:



Is the problem in the case of recipes that the provider of the page
navigation around the recipe is unwilling to license the navigation 
bits under the same license as the content proper?


I thought Toby's example was that each recipe on the page needed a 
different licence, rather than a distinction between the main 
content area and the navigation.


Oh. That can be solved by giving each recipe its own URI & HTML page 
and scraping those pages instead of summary pages that might contain 
multiple recipes.


Sure. In which case the problem becomes "doing mashups where data 
needs to have different metadata associated is impossible", so the 
requirement is "enable mashups to carry different metadata about bits 
of the content that are from different sources.


A use case for this:

There are mapping organisations and data producers and people who take 
photos, and each may place different policies. Being able to keep that 
policy information helps people with further mashups avoiding 
violating a policy.


For example, if GreatMaps.com has a public domain policy on their 
maps, CoolFotos.org has a policy that you can use data other than 
images for non-commercial purposes, and Johan Ichikawa has a photo 
there of my brother's café, which he has licensed as "must pay money", 
then it would be reasonable for me to copy the map and put it in a 
brochure for the café, but not to copy the data and photo from 
CoolFotos. On the other hand, if I am producing a non-commercial guide 
to cafés in Melbourne, I can add the map and the location of the cafe 
photo, but not the photo itself.




It seems a scenario where a human should carefully evaluate each licence 
and perhaps put a careful and human readable prose into the mashed-up 
page, or a link to such a prose. Metadata may or may not be accurate 
(e.g. may be misplaced and not contain the whole license, or refer to a 
wrong kind of license, different from the one stated in the prose), but 
the whole prose (and perhaps only that) is legally binding for sure (I'm 
not aware of any international law recognizing metadata and/or 
machine-processable/machine-friendly extracted content as a valid legal 
agreement/notice - in your example, Johan Ichikawa might put the "must 
pay money" license in a span containing a metadata reference to a 
creative commons license, but only the "must pay money" license is 
surely valid as a legal notice, as far as I can tell).




Another use case:
My wife wants to publish her papers online. She includes an abstract 
of each one in a page, but because they are under different copyright 
rules, she needs to clarify what the rules are. A harvester such as 
the Open Access project can actually collect and index some of them 
with no problem, but may not be allowed to index others. Meanwhile, a 
human finds it more useful to see the abstracts on a page than have to 
guess from a bunch of titles whether to look at each abstract.





I'm not strongly for one solution or the other in this case (an actual 
choice may depend on several considerations, such as harvesters 
reputation, or the need to use metadata anyway for private purposes), 
but this case might be addressed by embedding each abstract in an 
iframe, so that human users would get all of them in a single page, 
while a harvester would need to navigate each page to index/copy it, and 
a proper metadata might be put into each page, or each page might have a 
different rule to restrict access (e.g. through a robot file, or the 
Access-Control semantics, or any kind of white- or black- lists), 
specially to prevent a malicious harvester (that is one deliberately 
ignoring metadata and licenses) from accessing certain contents.


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:
Email.it offre alle aziende il servizio di Email Marketing con pacchetti di 
invio a 10.000 utenti a soli 250 Euro
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8352&d=9-1

Re: [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 
 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 

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

[Charles McCathieNevile]

On Mon, 05 Jan 2009 00:17:39 +1100, Henri Sivonen  wrote:


On Jan 3, 2009, at 17:05, Dan Brickley wrote:

But perhaps a more practical concern is that it unfairly biases things  
towards popular languages - lucky English, lucky Spanish, etc., and  
those that lend themselves more to NLP analysis. The Web is for  
everyone, and people shouldn't be forced to read and write English to  
enjoy the latest advances in Web automation.


Some languages are higher in the pecking order than others when software  
development is prioritized, and RDFa cannot level the playing field here.


Suppose there's a use case that can be satisfactorily addressed by  
applying NLP heuristics to content for the top-tier languages. Even if  
there were an RDF mechanism for addressing the same use case without  
relying on natural language, software aimed for serving the top-tier  
languages would still do the NLP thing for the use case.


No. There is no reason for most developers to prefer one over the other  
under the circumstances described.


Clearly Google has an investment in text-harvesting in a bunch of  
languages. Equally clearly its competitors who are more sucessfeul in  
various languages (Yandex, Baidu, etc) have an investment in the  
technology they use.


But developing a new indexing process, there is no a priori reason to  
favour NLP over some other technique that is also satisfactory, and if you  
happen to be interested in a global market, it makes sense to develop a  
system that can be more easily adapted, other things being equal.

...
Instead of bearing the cost of developing a totally alternative  
technology stack for the other languages without benefiting from any  
spillover from the effort done for the top-tier languages, it makes more  
sense to invest the effort into building upon the reusable parts already  
developed for the top-tier languages.


Except that it turns out that the re-usable parts of most search engines,  
for the general developer, are pretty limited. Whereas the re-usable parts  
of the RDF stack are numerous, available for many different platforms,  
from GPL open source to bespoke commercial closed-source and everything  
between.


All this does not necessarily establish the case for using RDF in HTML, it  
is just meant to demonstrate that this particular case *against* doesn't  
seem to be established, to me.


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

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

[Charles McCathieNevile]

On Mon, 05 Jan 2009 01:21:33 +1100, Henri Sivonen  wrote:

On Jan 2, 2009, at 14:01, Benjamin Hawkes-Lewis wrote:

On 2/1/09 10:38, Henri Sivonen wrote:



Is the problem in the case of recipes that the provider of the page
navigation around the recipe is unwilling to license the navigation  
bits under the same license as the content proper?


I thought Toby's example was that each recipe on the page needed a  
different licence, rather than a distinction between the main content  
area and the navigation.


Oh. That can be solved by giving each recipe its own URI & HTML page and  
scraping those pages instead of summary pages that might contain  
multiple recipes.


Sure. In which case the problem becomes "doing mashups where data needs to  
have different metadata associated is impossible", so the requirement is  
"enable mashups to carry different metadata about bits of the content that  
are from different sources.


A use case for this:

There are mapping organisations and data producers and people who take  
photos, and each may place different policies. Being able to keep that  
policy information helps people with further mashups avoiding violating a  
policy.


For example, if GreatMaps.com has a public domain policy on their maps,  
CoolFotos.org has a policy that you can use data other than images for  
non-commercial purposes, and Johan Ichikawa has a photo there of my  
brother's café, which he has licensed as "must pay money", then it would  
be reasonable for me to copy the map and put it in a brochure for the  
café, but not to copy the data and photo from CoolFotos. On the other  
hand, if I am producing a non-commercial guide to cafés in Melbourne, I  
can add the map and the location of the cafe photo, but not the photo  
itself.


Another use case:
My wife wants to publish her papers online. She includes an abstract of  
each one in a page, but because they are under different copyright rules,  
she needs to clarify what the rules are. A harvester such as the Open  
Access project can actually collect and index some of them with no  
problem, but may not be allowed to index others. Meanwhile, a human finds  
it more useful to see the abstracts on a page than have to guess from a  
bunch of titles whether to look at each abstract.


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

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

[Henri Sivonen]

On Jan 2, 2009, at 14:01, Benjamin Hawkes-Lewis wrote:


On 2/1/09 10:38, Henri Sivonen wrote:
More to the point, Microformats not only require per-format  
processing
but the processing required for each Microformat isn't specified at  
all.

That's bad.


Some do have processing specified (at least to some degree):

http://microformats.org/wiki/hcard-parsing


That's still not a proper parsing spec. Do all microformat consumers  
with significant market share do it that way?


For the rest, this seems like something fixable, so I'm not sure how  
this is more to the point?


HTML parsing is fixable, too, but actually fixing it is something that  
didn't happen until the fixing effort was taken to the spec level.


* http://microformats.org/wiki/parsing-brainstorming (attempt to  
actually specify precise parsing rules for all microformats)


This one I hadn't seen before. It's clearly a step into a more spec- 
like direction.



It could of course be the RDFa curie is worse than the disease.


I suspect that is the case.


Is the problem in the case of recipes that the provider of the page
navigation around the recipe is unwilling to license the navigation  
bits

under the same license as the content proper?


I thought Toby's example was that each recipe on the page needed a  
different licence, rather than a distinction between the main  
content area and the navigation.


Oh. That can be solved by giving each recipe its own URI & HTML page  
and scraping those pages instead of summary pages that might contain  
multiple recipes.



In the case of images, why should a program inferring something about
licensing trust assertions made in a different HTTP resource  
(possibly

even from a different Origin)?


Why should it trust assertions made in the same resource?

For example, presumably you could download an image, change its  
licencing metadata, and host it at your own Origin? Admittedly,  
that's a little more work than just hotlinking.


Good point. That's a problem if you are examining a previously unknown  
and untrusted site that might have all its content copied from  
somewhere else. Trusting the origin of the data for it licensing does  
help, though, if you are browsing a site you believe to be reputable  
and clueful and want to automate the license discovery part only.


--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

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

[Henri Sivonen]

On Jan 3, 2009, at 17:05, Dan Brickley wrote:

But perhaps a more practical concern is that it unfairly biases  
things towards popular languages - lucky English, lucky Spanish,  
etc., and those that lend themselves more to NLP analysis. The Web  
is for everyone, and people shouldn't be forced to read and write  
English to enjoy the latest advances in Web automation.


Some languages are higher in the pecking order than others when  
software development is prioritized, and RDFa cannot level the playing  
field here.


Suppose there's a use case that can be satisfactorily addressed by  
applying NLP heuristics to content for the top-tier languages. Even if  
there were an RDF mechanism for addressing the same use case without  
relying on natural language, software aimed for serving the top-tier  
languages would still do the NLP thing for the use case. Thus, the  
development of the parallel RDF-based solution would be borne by the  
communities using the other languages. If the other languages can't  
get the users of the top-tier languages to use the same technical  
solution, they are still at a disadvantage even if an alternative  
technology stack is theoretically possible, because most software  
development effort goes into what makes sense for the top-tier  
languages without the results being applicable also for the other  
languages.


Instead of bearing the cost of developing a totally alternative  
technology stack for the other languages without benefiting from any  
spillover from the effort done for the top-tier languages, it makes  
more sense to invest the effort into building upon the reusable parts  
already developed for the top-tier languages.


(Quick case study about language-sensitive technology adoption and  
markets: When movable type was developed, a *subset* of the alphabet  
used for German--the native language of printing press suppliers--was  
adopted for Finnish. Today, hundreds of years later, digital font  
availability for Finnish is better than font availability for  
languages of comparable installed base that adopted *extensions* for  
the alphabet used for German or that used a totally different script.  
That is, NIH *still* hasn't caught up with the first-mover advantage  
as far as type goes.)


--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

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

[Ian Hickson]

On Sun, 4 Jan 2009, Charles McCathieNevile wrote:
>
> And my further question to Ian is what are the criteria for deciding 
> whether a case is sufficient.

The process is described here:

   
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_the_spec.3F

Deciding whether we need to address a problem or set of use cases is a 
judgement call. The more people a problem affects, the stronger the case 
for fixing it.

Right now I'm still trying to work out what the problem is; most of the 
discussions seem to be centering around RDF, RDFa, and microformats, which 
are solutions, not problems. It has been asserted that problems exist, and 
that they have characteristics for which RDFa is suitable as a solution, 
but detailed descriptions of the problems themselves have been rather 
lacking. Without a clear description of the problem(s) of relevance, 
discussing solutions is meaningless, for we can't evaluate them.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

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

[Charles McCathieNevile]

On Sun, 04 Jan 2009 16:37:08 +1100, timeless  wrote:

On Sun, Jan 4, 2009 at 3:49 AM, Charles McCathieNevile  
 wrote:
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.


dunno. i use google to search apple, msdn, and a number of other
technical resources because the actual technical resource search
engines are unusable/useless.


Sure. That's wonderful that Google are so good (or sad that the people who  
make the information you rely on are so useless).



i also use gmail (which i presume shares some intelligence with
google) to manage access to bug databases, because it's faster/smarter
than the actual database search engine..


And I use my Opera's filters to search for certain things because they are  
far more efficient than the full-text search I also use. It depends on the  
use cases.


My point is not that Google is bad. It is that there are all kinds of  
search where it is not the best. One set are those which reliy on faceted  
information and on well-developed metadata. I don't know what searches you  
do, but I know that some databases I search are dreadfully maintained and  
free-text is the only sensible approach, while others are well-designed  
and I can get better results from a tool designed for the job I am trying  
to do.


Anecdotal evidence that demonstrates there is a use case for Google is  
something we probably don't need. I think that we are all convinced that  
Ian's employer is important - not least because it kindly pays Ian for his  
work. I think the question is to establish what cases doesn't Google  
serve. (Well, and the rest of the search engine market, who I believe are  
the majority of searches performed globally even on the public internet).  
And my further question to Ian is what are the criteria for deciding  
whether a case is sufficient.


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

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

[timeless]

On Sun, Jan 4, 2009 at 3:49 AM, Charles McCathieNevile  wrote:
> 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.

dunno. i use google to search apple, msdn, and a number of other
technical resources because the actual technical resource search
engines are unusable/useless.

i also use gmail (which i presume shares some intelligence with
google) to manage access to bug databases, because it's faster/smarter
than the actual database search engine..

the same ime generally applies to wikis (the search engines are awful).

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

[Calogero Alex Baldacchino]

Toby A Inkster ha scritto:

Calogero Alex Baldacchino wrote:


My concern is: is RDFa really suitable for everyone and for Web
automation? My own answer, at first glance, is no. That's because RDF(a)
can perhaps address nicely very niche needs, where determining how much
data can be trusted is not a problem, but in general misuses AND
deliberate abuses may harm automation heavily


If your agent isn't going to trust the data gleaned from RDFa, then 
why should it trust the data gleaned from the web page's natural 
language? If the page has been authored by a reprobate that cannot be 
trusted to put honest and correct data in a few RDFa attributes, why 
should we trust their prose text?




If you sell computers but your site talks about cars I'll never buy a 
notebook from you; thus you're not cheating me, but yourself and 
damaging your business. But if you believe cars are searched more often 
than computers (just an example), one may use false metadata to cheat 
any UAs relying on metadata instead of prose, and take me on a store 
selling computers instead of cars.


Reliability of metadata (with respect to the described data) is an issue 
separated from reliability of content: it's not up to any UA to 
understand AND filter content basing on the author being trusted to be 
saing the truth (such would be a form of censorship), but if I ask the 
UA to bring me a page talking about horses, I don't want it to bring me 
a page talking about v.i.a.g.r.a. (that's spam), thus it is up to any UA 
relying on metadata to understand AND filter them basing on their 
reliability.


An oft-quoted answer is that the prose text is "visible" whereas the 
RDFa is somehow "invisible". Apart from the fact that UIs which make 
use of data pulled in from RDFa will make this data visible, there is 
also the fact that RDFa, unlike an external RDF/XML file, or some 
metadata embedded in a 

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

[Charles McCathieNevile]

On Sun, 04 Jan 2009 02:54:18 +1100, Håkon Wium Lie 
wrote:


Also sprach Dan Brickley:

 > My main problem with the natural language processing option is that it
 > feels too close to waiting for Artificial Intelligence. I'd rather  >  
add 6 attributes to HTML and get on with life.

...

Personally, I think the 'class' attribute may still be a more
compelling option in a less-is-more way. It already exists and can
easily be used for styling purposes. Styling is bait for authors to
disclose semantics.


I agree that this is a clear first step - and microformats were developed
by paving a cowpath from authors who had done this on their own initiative.

I think the reason for adding the RDFa attributes is that there are cases
where the semantic richness offered by class is insufficient. The relevant
cases are where people are already dealing in rich formalised semantics,
not those where it is a battle to get people to provide any semantics at
all. I think there is a clear benefit in drawing these people to HTML5
rather than suggesting they go off into some different Web.

I used the pattern of adding semantics through class, a decade or so ago,
and in some cases it met my needs perfectly, but in others was
insufficient to enable re-use of the data directly from pages, and forced
me to adopt external systems for managing my data which in turn implied an
increased cost in management because I had to keep the data model clear
although I did not have a simple formalism to specify it at the time.

cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
  je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

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

[Charles McCathieNevile]

On Sun, 04 Jan 2009 03:51:53 +1100, Calogero Alex Baldacchino  
 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). 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.



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.




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 

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

[Charles McCathieNevile]

On Sat, 03 Jan 2009 04:52:35 +1100, Tab Atkins Jr.   
wrote:



On Fri, Jan 2, 2009 at 12:12 AM, Charles McCathieNevile
 wrote:
On Fri, 02 Jan 2009 05:43:05 +1100, Andi Sidwell   
wrote:



On 2009-01-01 15:24, Toby A Inkster wrote:


The use cases for RDFa are pretty much the same as those for
Microformats.


Right, but microformats can be used without any changes to the HTML
language, whereas RDFa requires such changes.  If they fulfill the  
same use

cases, then there's not much point in adding RDFa.


...


Why the non-response?


Because the response comes in the next paragraph, to the first question  
that was worth asking.



So why RDFa and not Microformats?


(I think the question should be why RDFa is needed *as well as*  
µformats)


This is correct.  Microformats exist already.  They solve current
problems.


(Elsewhere in this thread you wrote
[[[
It has not yet been established that there is a problem worth solving that  
metadata would address at all.

]]]
Do you consider that µformats do not encode metadata? Otherwise, I am not  
sure how to reconcile these statements. In any case I would greatly  
appreciate clarification of what you think microformats do, since I do  
believe that microformats are very explicitly directed to allowing the  
encoding of metadata, anbd therefore it is not clear that we are  
discussing from similar premises).



 Are there further problems that Microformats don't address
which can be solved well by RDFa?  Are these problems significant
enough to authors to be worth addressing in the spec, or can we wait
and let the community work out its own solutions further before we
make a move?


In my opinion, yes there are further problems µformats don't solve (that  
RDFa does), yes they are significant, and the community has come up with a  
way to solve them - RDFa.



Microformats are the metadata equivalent of Flash-based video players.
 They are hacks used to allow authors to accomplish something not
explicitly accounted for in the language.  Are there significant
problems with this approach?


Yes. The problems are that they rely on precoordination on a  
per-vocabulary basis before you can do anything useful with the data. In  
practical usage they rely on choosing attribute names that hopefully don't  
clash with anything - in other words, trying to solve the problem of  
disambiguation that namespaces solves, but by choosing names that are  
wierd enough not to clash or by circumscribing the problem spaces that can  
be addressed to the extent that you can expect no clashes.


(This is hardly news, by the way).


Is metadata embedding used widely enough
to justify extending the language for it, or are the current hacks
(Microformats, in this case) enough?  Are current metadata embedding
practices mature enough that we can be relatively sure we're solving
actual problems with our extension?


Current metadata embedding is done using µformats, and it's pretty clear  
that they are not sufficient. A large body of work uses RDF data models  
(Dublin Core, IMS, LOM, FOAF, POWDER are all large-scale formats. The  
people who are testing RDF engines with hundreds of millions of triples  
and more are doing it with real data, not stuff generated for the  
experiment).


It is also clear that people would like to develop further small-scale  
formats, and that µformats through its requirement for community  
consultation is effectively too heavyweight for the purposes of many  
developers.



 These are all questions that must
be asked of any extention to the language.


Firstly, RDFa provides a single unified parsing algorithm that
Microformats do not. ...



This is not necessarily beneficial.  If you have separate parsing
algorithms, you can code in shortcuts for common use-cases and thus  
optimise the authoring experience.


On the other hand, you cannot parse information until you know how it is
encoded, and information encoded in RDFa can be parsed without knowing  
more.


And not only can you optimise your parsing for a given algorithm, you  
can also do for a known vocabulary - or you can optimise the

post-parsing treatment.


What is the benefit to authors of having an easily machine-parsed
format?


Assuming that the format is sufficiently easy to write, and to generate, I  
am not sure what isn't obvious about the answer to the question.


(In case I am somehow very clever, and others aren't, the benefit is that  
it is easy to machine parse and use the information).



Are they greater than the benefits of a
format that is harder to parse, but easier for authors to write?


For a certain set of authors, yes the benefits are greater.


 Also, as has been pointed out before in the distributed extensibility
debate, parsing is a very small part of doing useful things with  
content.


Yes. However many of the use cases that I think justify the inclusion of
RDFa are already very small on their own, and valuable when several
vocabularies are combined. So 

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

[Toby A Inkster]

Calogero Alex Baldacchino wrote:


My concern is: is RDFa really suitable for everyone and for Web
automation? My own answer, at first glance, is no. That's because  
RDF(a)
can perhaps address nicely very niche needs, where determining how  
much

data can be trusted is not a problem, but in general misuses AND
deliberate abuses may harm automation heavily


If your agent isn't going to trust the data gleaned from RDFa, then  
why should it trust the data gleaned from the web page's natural  
language? If the page has been authored by a reprobate that cannot be  
trusted to put honest and correct data in a few RDFa attributes, why  
should we trust their prose text?


An oft-quoted answer is that the prose text is "visible" whereas the  
RDFa is somehow "invisible". Apart from the fact that UIs which make  
use of data pulled in from RDFa will make this data visible, there is  
also the fact that RDFa, unlike an external RDF/XML file, or some  
metadata embedded in a 

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

[Calogero Alex Baldacchino]

Dan Brickley ha scritto:

On 3/1/09 14:02, Julian Reschke wrote:

Tab Atkins Jr. wrote:

The most successful alternative is nothing at all. ^_^ We can
extract copious data from web pages reliably without metadata, either
using our human senses (in personal use) or natural-language-based
processing (in search engine use). It has not yet been established
that sufficient and significant enough problems *exist* to justify a
solution, let alone one that requires an addition to html. That is
what Ian is specifically looking for.


That's what you and Ian claim. Many disagree.


My main problem with the natural language processing option is that it 
feels too close to waiting for Artificial Intelligence. I'd rather add 
6 attributes to HTML and get on with life.


But perhaps a more practical concern is that it unfairly biases things 
towards popular languages - lucky English, lucky Spanish, etc., and 
those that lend themselves more to NLP analysis. *The Web is for 
everyone*, and people shouldn't be forced to read and write English to 
enjoy the latest advances in *Web automation*. Since HTML5 is going 
through W3C, such considerations need to be taken pretty seriously.




My concern is: is RDFa really suitable for everyone and for Web 
automation? My own answer, at first glance, is no. That's because RDF(a) 
can perhaps address nicely very niche needs, where determining how much 
data can be trusted is not a problem, but in general misuses AND 
deliberate abuses may harm automation heavily, since an automaton is 
unlikely to be able to understand whether metadata express the real 
meaning of a web page or not (without a certain degree of AI).


If an external mechanism is needed to determine trust level for 
metadata, that is to establish when an automation results are good or 
bad, such a mechanism may involve human beings at some stage, thus 
breaking automation (this is somehow similar to the problem of defining 
an "oracle machine" described by Turing, according to whom such a 
machine isn't an automaton).


On another hand, a very custom model thought for very custom needs (and 
not requiring wide support) may be less prone to abuses, since it's 
unlikely to find someone willing to cheat himself. Thus, having third 
parties agreeing a certain model and related APIs, and implementing APIs 
on their own sides, might be more reliable in some cases (anyway, third 
parties should agree their respective metadata are reliable and find a 
way to evaluate they really are).


Dan Brickley ha scritto:

On 3/1/09 16:54, Håkon Wium Lie wrote:

Also sprach Dan Brickley:

  >  My main problem with the natural language processing option is 
that it
  >  feels too close to waiting for Artificial Intelligence. I'd 
rather add 6

  >  attributes to HTML and get on with life.

:-)


Another thought re NLP. RDFa (and similar, ...) are formats that can 
be used for writing down the conclusions of NLP analysis. For example 
here see the BBC's recent Muddy Boots experiment, using DBPedia 
(Wikipedia in RDF) data to drive autoclassification / named entity 
recognition. So here we can agree with Ian and others that text 
analysis has much to offer, and still use RDFa (or other semantic 
markup - i'll sidestep that debate for now) as a notation for marking 
up the words with a machine-friendly indicator of their NLP-guessed 
meaning.


http://www.bbc.co.uk/blogs/journalismlabs/2008/12/muddy_boots.html


Personally, I think the 'class' attribute may still be a more
compelling option in a less-is-more way. It already exists and can
easily be used for styling purposes. Styling is bait for authors to
disclose semantics.


I'm sure there's mileage to be had there. I'm somehow incapable of 
writing XSLT so GRDDL hasn't really charmed me, but 'class' certainly 
corresponds to a lot of meaningful markup. Naturally enough it is 
stronger at tagging bits of information with a category than at 
defining relationships amongst the things defined when they're 
scattered around the page. But that's no reason to dismiss it entirely.


Did you see the RDF-EASE draft, 
http://buzzword.org.uk/2008/rdf-ease/spec? From which comes: "Ten 
second sales pitch: CSS is an external file that specifies how your 
document should look; *RDF-EASE is an external file that specifies 
what your document means.*"


RDF-EASE uses CSS-based syntax. More discussion here, 
http://lists.w3.org/Archives/Public/semantic-web/2008Dec/0148.html 
including question of whether it ought to be expressed using 
css3-namespace, 
http://lists.w3.org/Archives/Public/semantic-web/2008Dec/0175.html


chers,

Dan

--
http://danbri.org/



My question is: how often can I trust such a file specifies what your 
document really means, without evaluating its content?


I'd distinguish two cases (not pretendig to make a complete classification),

- The semantics described by metadata is used for server-side 
computations: there's no need to evaluate content (since I'm trusting to 
you when 

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

[Calogero Alex Baldacchino]

Charles McCathieNevile ha scritto:

The results of the first set of Microformats efforts were some pretty
cool applications, like the following one demonstrating how a web
browser could forward event information from your PC web browser to 
your

phone via Bluetooth:

http://www.youtube.com/watch?v=azoNnLoJi-4


It's a technically very interesting application. What has the adoption
rate been like? How does it compare to other solutions to the problem,
like CalDav, iCal, or Microsoft Exchange? Do people publish calendar
events much? There are a lot of Web-based calendar systems, like 
MobileMe

or WebCalendar. Do people expose data on their Web page that can be used
to import calendar data to these systems?


In some cases this data is indeed exposed to Webpages. However, 
anecdotal evidence (which unfortunately is all that is available when 
trying to study the enormous collections of data in private intranets) 
suggests that this is significantly more valuable when it can be done 
within a restricted access website.


...

In short, RDFa addresses the problem of a lack of a standardized
semantics expression mechanism in HTML family languages.


A standardized semantics expression mechanism is a solution. The lack 
of a solution isn't a problem description. What's the problem that a

standardized semantics expression mechanism solves?


There are many many small problems involving encoding arbitrary data 
in pages - apparently at least enough to convince you that the data-* 
attributes are worth incorporating.


There are many cases where being able to extract that data with a 
simple toolkit from someone else's content, or using someone else's 
toolkit without having to tell them about your data model, solves a 
local problem. The data-* attributes, because they do not represent a 
formal model that can be manipulated, are insufficient to enable 
sharing of tools which can extract arbitrary modelled data.




That's because the data-* attributes are meant to create custom models 
for custom use cases not (necessarily) involving interchange and (let me 
say) "agnostic extraction" of data. However, data-* attributes might be 
used to "emulate" support for RDFa attributes, so that each one might be 
mapped to, let's say, a "data-rdfa-" one and viceversa (I 
don't think "data-rdfa-about" vs "about" would make a great difference, 
at least in a test phase, since it wouldn't be much different from 
"rdfa:about", which might be used to embed RDFa attributes in a somewhat 
xml language (e.g. an "external" markup embedded in a xhtml document 
through the extension mechanism)).


Since it seems there are several problems which may be addressed (beside 
other, more custom models) by RDFa for organization-wide internal use 
and intranet publication, without the explicit requirement of external 
interchange, when both HTML5 specific features and RDFa attributes are 
felt as necessary, it shouldn't be too difficoult to create a custom 
parser, comforming to RDFa spec and availing of data-* attributes, to be 
plugged in a certain browser supporting html5 (and data-*) for internal 
test first, then exposed to the community, so that html5+rdfa can be 
tested on a wider scale (especially once alike parsers are provided for 
all main browsers), looking for a widespread adoption to point out an 
effective need to merge RDFa into HTML5 spec (or to standardize an 
approach based on 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.



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, 
and it is not clear to me how just creating an explicit relationship 
between properties is enough to ensure that a property really represents 
a subject and not a predicate or an object (in its wrongly documented 
schema), if the problem is the correct definition of the properties 
themselves. Perhaps it is enough to 

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

[Giovanni Campagna]

I've tried to follow all the discussion besides of its lengths and my
conclusion is:
You're asking the wrong question

People against RDFa in HTML5 are asking "why do you need RDFa?", and
supporters of the proposal are actually describing the benefits of RDFa
itself.

The right question is: why do you need RDFa *inside HTML5*?

My personal answer to this question is:
There is no needing for RDFa inside HTML5. There are other markup languages
which support RDFa natively (XHTML for example).
You may say that in this way you help to divide the web in two sides, users
of HTML5 and users of XHTML2.

Actually the web, is already divided in two big groups:
- Web of data
- Web of interaction

Web of data means all the page whose primary objective is to provide some
information, either user-readable or machine-readable to the users, while
web of interaction include web application, whose primary purpose is to
provide additional services to the users.
These two groups have very different requirements (GMail doesn't need RDFa
in application code, while Wikipedia doesn't need a progress element), so
specific markup languages may suit better the web site.
Moreover, this distinction is not a requirement, is just an advice: you can
put metadata inside HTML5 using Microformats and you can put interactivity
inside XHTML2 using XMLEvents.

Summing up: if you author feel the absolute needing for metadata, because
delivering content to the users is your primary goal, then switch from HTML5
to something else, and leave HTML5 to web application, focused on user
interaction.

Giovanni

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

[Dan Brickley]

On 3/1/09 16:54, Håkon Wium Lie wrote:

Also sprach Dan Brickley:

  >  My main problem with the natural language processing option is that it
  >  feels too close to waiting for Artificial Intelligence. I'd rather add 6
  >  attributes to HTML and get on with life.

:-)


Another thought re NLP. RDFa (and similar, ...) are formats that can be 
used for writing down the conclusions of NLP analysis. For example here 
see the BBC's recent Muddy Boots experiment, using DBPedia (Wikipedia in 
RDF) data to drive autoclassification / named entity recognition. So 
here we can agree with Ian and others that text analysis has much to 
offer, and still use RDFa (or other semantic markup - i'll sidestep that 
debate for now) as a notation for marking up the words with a 
machine-friendly indicator of their NLP-guessed meaning.


http://www.bbc.co.uk/blogs/journalismlabs/2008/12/muddy_boots.html


Personally, I think the 'class' attribute may still be a more
compelling option in a less-is-more way. It already exists and can
easily be used for styling purposes. Styling is bait for authors to
disclose semantics.


I'm sure there's mileage to be had there. I'm somehow incapable of 
writing XSLT so GRDDL hasn't really charmed me, but 'class' certainly 
corresponds to a lot of meaningful markup. Naturally enough it is 
stronger at tagging bits of information with a category than at defining 
relationships amongst the things defined when they're scattered around 
the page. But that's no reason to dismiss it entirely.


Did you see the RDF-EASE draft, 
http://buzzword.org.uk/2008/rdf-ease/spec? From which comes: "Ten second 
sales pitch: CSS is an external file that specifies how your document 
should look; RDF-EASE is an external file that specifies what your 
document means."


RDF-EASE uses CSS-based syntax. More discussion here, 
http://lists.w3.org/Archives/Public/semantic-web/2008Dec/0148.html 
including question of whether it ought to be expressed using 
css3-namespace, 
http://lists.w3.org/Archives/Public/semantic-web/2008Dec/0175.html


chers,

Dan

--
http://danbri.org/

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

[Håkon Wium Lie]

Also sprach Dan Brickley:

 > My main problem with the natural language processing option is that it 
 > feels too close to waiting for Artificial Intelligence. I'd rather add 6 
 > attributes to HTML and get on with life.

:-)

Personally, I think the 'class' attribute may still be a more
compelling option in a less-is-more way. It already exists and can
easily be used for styling purposes. Styling is bait for authors to
disclose semantics.

Cheers,

-h&kon
  Håkon Wium Lie  CTO °þe®ª
howc...@opera.com  http://people.opera.com/howcome

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

[Dan Brickley]

On 3/1/09 14:02, Julian Reschke wrote:

Tab Atkins Jr. wrote:

...

Well, it'll require an N3 parser where previously none was needed.


RDFa requires an RDFa parser as well, and in general *any* metadata
requires a parser, so this point is moot. The only metadata that
doesn't require a parser is no metadata at all.


With RDFa, most of the parsing is done by HTML. So I would call it an
"RDFa processor". And yes, that doesn't change the fact that code needs
to be written. But it affects the type of the code that needs to be
written.


Somewhat of an aside, but for the curious - here is an RDFa 
parser/processor app:


http://code.google.com/p/rdfquery/wiki/Introduction
example: http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html
js: http://rdfquery.googlecode.com/svn/trunk/jquery.rdfa.js

[...]


The most successful alternative is nothing at all. ^_^ We can
extract copious data from web pages reliably without metadata, either
using our human senses (in personal use) or natural-language-based
processing (in search engine use). It has not yet been established
that sufficient and significant enough problems *exist* to justify a
solution, let alone one that requires an addition to html. That is
what Ian is specifically looking for.


That's what you and Ian claim. Many disagree.


My main problem with the natural language processing option is that it 
feels too close to waiting for Artificial Intelligence. I'd rather add 6 
attributes to HTML and get on with life.


But perhaps a more practical concern is that it unfairly biases things 
towards popular languages - lucky English, lucky Spanish, etc., and 
those that lend themselves more to NLP analysis. The Web is for 
everyone, and people shouldn't be forced to read and write English to 
enjoy the latest advances in Web automation. Since HTML5 is going 
through W3C, such considerations need to be taken pretty seriously.



As a note, this isn't the W3C's HTML WG. The WHATWG is independent
from the W3C.


But the WHATWG HTML5 *work* is no longer entirely independent of W3C; 
the two organizations embarked on a major joint venture. It seems 
reasonable for members of the WHATWG world to take W3C-oriented 
considerations seriously, regardless of mailing list.


cheers,

Dan

--
http://danbri.org/

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

[Julian Reschke]

Tab Atkins Jr. wrote:

...

Well, it'll require an N3 parser where previously none was needed.


RDFa requires an RDFa parser as well, and in general *any* metadata
requires a parser, so this point is moot.  The only metadata that
doesn't require a parser is no metadata at all.


With RDFa, most of the parsing is done by HTML. So I would call it an 
"RDFa processor". And yes, that doesn't change the fact that code needs 
to be written. But it affects the type of the code that needs to be written.



...
I have no idea.  The point is, though, that it *is* an existing
possibility that requires no further effort from this working group or
browser developers.  As such, if it solves the problem (whatever it
is, since that hasn't yet been well-established) sufficiently, we can
leave it alone.  It is in the best interests of everybody if a
solution can be found without any changes to the language, because it
means browser uptake is quick (immediate and retroactive, to be
precise ^_^).
...


Well, there are lots of conditionals in this statement :-)


We have to ensure that the problem isn't already solved by the
language first, and only after that can we evaluate whether the
language is the correct place to solve the problem, and only after
*that* can we start discussing how to actually go about solving the
problem in the language.  Too much of this discussion is jumping
straight to step 3, so Ian, I, and others are trying to focus it on
step 1.


I would say this is because the research and design in this area totally 
predates HTML5. Are you seriously suggesting that all of that needs to 
start from scratch?



...
Not quite correct.  Again, the problem of embedded shareable data in a
web page has been solved multiple times.  The specific problem of
sharing *RDF* data (due to needing/wanting the specific benefits RDF
can offer) has also been solved.  What are the precise problems that
require *RDFa* as a solution?
...

Could you elaborate a bit on these solutions?


Microformats, embedded data in 

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

[Tab Atkins Jr.]

On Fri, Jan 2, 2009 at 12:02 PM, Julian Reschke  wrote:
> Tab Atkins Jr. wrote:

 Right, but microformats can be used without any changes to the HTML
 language, whereas RDFa requires such changes.  If they fulfill the same
 use
 cases, then there's not much point in adding RDFa.
>>>
>>> ...
>>
>> Why the non-response?  This is precisely the point of contention.
>> Things aren't added to the spec on a whim.  Things get added when it
>> is demonstrated that authors will significantly benefit from the
>> inclusion of the feature in the language.  Microformats (used as an
>> example only) use only features already in the language, and thus do
>> not need any spec support.  If they already solve the problem
>> adequately, then there is no need to go further.
>> ...
>
> I think the supporters of RDFa (me included) claim that Microformats only
> address a subset of the problem solved by RDFa.

The next step, then, is to list these problems, establish that they
truly aren't solved by existing solutions (not just Microformats),
establish that solving them would be of significant benefit to
authors, and finally that solving them within HTML is the most
appropriate course of action.

> So why RDFa and not Microformats?
>>>
>>> (I think the question should be why RDFa is needed *as well as* µformats)
>>
>> This is correct.  Microformats exist already.  They solve current
>> problems.  Are there further problems that Microformats don't address
>> which can be solved well by RDFa?  Are these problems significant
>> enough to authors to be worth addressing in the spec, or can we wait
>> and let the community work out its own solutions further before we
>> make a move?  We generally want to wait until a given item is truly
>> established before speccing it, so that we can work with existing
>
> Oh really? That's news to me.
>
> If this is principle we agree on that we really should start cutting lots of
> things from the spec.

It is a general principle, though not a necessary one.  As Ian noted
in his earlier email, speccing a solution too early runs the risk of
solving the wrong problem, and then poisoning that area of the
solution space entirely.  If we wait for authors to develop their own
hacks around features missing in the language, we can be sure that
we're solving a problem authors want solved, and we have some measure
of implementation experience already (even if just in author-deployed
Javascript) that we can learn from.  Other groups use this principle
as well - browser vendors prefix their early versions of new CSS
properties, for example, so that authors using these early versions
don't poison the space and prevent problems from being addressed that
would 'break' uses of the property.

Most the additions in HTML5 are designed on this principle.  For
example, the  element and the additional values for  are
drawn directly from javascript and flash-based solutions currently in
use, with the intent to make them easier for authors to use.  Others,
such as the additional sectioning elements and the new header-parsing
algorithm, were meant to embrace and bless well-established authoring
practices (splitting your content into header, footer, and content
s, or building documents from smaller fragments which use 
and such with clear intent to create a .  Finally, some additions (the
Workers spec, the SQL spec) have little in the way of current-practice
analogues (though much of those things are presaged in Gears, frex)
because they are designed to specifically address a current lack and
enable future uses.  These, though, still solve well-defined problems
and bring benefits which significantly outweigh their downsides.

RDFa isn't a well-established authoring pattern needing to be blessed
and made explicit.  That means it's either a simplification of
existing widespread hacks (Microformats?) intended to make authors
lives easier, or it's intended to fill a gaping hole that can be
established to be of significant benefit to authors to have filled.
Either way, one needs some justification.

Frex, it's possible that the language *could* be extended to make
Microformat-type things easier to use for authors.  We'd need to
establish that Microformats (or some other embedded metadata) really
are commonly used, though, and that the proposed simplification is
really significant enough (existing validation and video libraries,
for example, are much more complex to use than  or
, and can impose significant extra bandwidth costs which are
undesirable).

It's also possible that embedded metadata support *is* a gaping hole
that needs to be filled.  We'd still need to (a) establish the problem
clearly (so we can evaluate possible solutions) and (b) decide that
RDFa is a good solution to the problem as stated before we add it into
the language.

~TJ

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

[Tab Atkins Jr.]

On Fri, Jan 2, 2009 at 11:55 AM, Julian Reschke  wrote:
> Tab Atkins Jr. wrote:
>>
>> ...
>> Solutions for this already exist; embedded N3 in a 

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

[Julian Reschke]

Tab Atkins Jr. wrote:

Right, but microformats can be used without any changes to the HTML
language, whereas RDFa requires such changes.  If they fulfill the same use
cases, then there's not much point in adding RDFa.

...


Why the non-response?  This is precisely the point of contention.
Things aren't added to the spec on a whim.  Things get added when it
is demonstrated that authors will significantly benefit from the
inclusion of the feature in the language.  Microformats (used as an
example only) use only features already in the language, and thus do
not need any spec support.  If they already solve the problem
adequately, then there is no need to go further.
...


I think the supporters of RDFa (me included) claim that Microformats 
only address a subset of the problem solved by RDFa.



So why RDFa and not Microformats?

(I think the question should be why RDFa is needed *as well as* µformats)


This is correct.  Microformats exist already.  They solve current
problems.  Are there further problems that Microformats don't address
which can be solved well by RDFa?  Are these problems significant
enough to authors to be worth addressing in the spec, or can we wait
and let the community work out its own solutions further before we
make a move?  We generally want to wait until a given item is truly
established before speccing it, so that we can work with existing


Oh really? That's news to me.

If this is principle we agree on that we really should start cutting 
lots of things from the spec.



...



Best regards, Julian

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

[Julian Reschke]

Tab Atkins Jr. wrote:

...
Solutions for this already exist; embedded N3 in a 

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

[Tab Atkins Jr.]

On Fri, Jan 2, 2009 at 12:12 AM, Charles McCathieNevile
 wrote:
> On Fri, 02 Jan 2009 05:43:05 +1100, Andi Sidwell  wrote:
>
>> On 2009-01-01 15:24, Toby A Inkster wrote:
>>>
>>> The use cases for RDFa are pretty much the same as those for
>>> Microformats.
>>
>> Right, but microformats can be used without any changes to the HTML
>> language, whereas RDFa requires such changes.  If they fulfill the same use
>> cases, then there's not much point in adding RDFa.
>
> ...

Why the non-response?  This is precisely the point of contention.
Things aren't added to the spec on a whim.  Things get added when it
is demonstrated that authors will significantly benefit from the
inclusion of the feature in the language.  Microformats (used as an
example only) use only features already in the language, and thus do
not need any spec support.  If they already solve the problem
adequately, then there is no need to go further.

>>> So why RDFa and not Microformats?
>
> (I think the question should be why RDFa is needed *as well as* µformats)

This is correct.  Microformats exist already.  They solve current
problems.  Are there further problems that Microformats don't address
which can be solved well by RDFa?  Are these problems significant
enough to authors to be worth addressing in the spec, or can we wait
and let the community work out its own solutions further before we
make a move?  We generally want to wait until a given item is truly
established before speccing it, so that we can work with existing
use-cases and solve known problems.  To do otherwise risks us
inventing use-cases that don't commonly exist in reality, solving
non-problems while leaving gaping holes that will cause authors
problems down the line.

For an example (used several times, but that's because it's a really
good example), consider .  Flash-based video players are
already extremely common.  We know how people use them, we know what
authors generally expect from them, and we know what problems exist
with how they are currently implemented and used.  We also feel that
extending the language would allow us to solve these problems, and
help authors significantly.  Thus, .

Microformats are the metadata equivalent of Flash-based video players.
 They are hacks used to allow authors to accomplish something not
explicitly accounted for in the language.  Are there significant
problems with this approach?  Is metadata embedding used widely enough
to justify extending the language for it, or are the current hacks
(Microformats, in this case) enough?  Are current metadata embedding
practices mature enough that we can be relatively sure we're solving
actual problems with our extension?  These are all questions that must
be asked of any extention to the language.

>>> Firstly, RDFa provides a single unified parsing algorithm that
>>> Microformats do not. ...
>
>> This is not necessarily beneficial.  If you have separate parsing
>> algorithms, you can code in shortcuts for common use-cases and thus optimise
>> the authoring experience.
>
> On the other hand, you cannot parse information until you know how it is
> encoded, and information encoded in RDFa can be parsed without knowing more.
>
> And not only can you optimise your parsing for a given algorithm, you can
> also do for a known vocabulary - or you can optimise the post-parsing
> treatment.

What is the benefit to authors of having an easily machine-parsed
format?  (Note: this is completely separate from the question of the
benefits of metadata at all.)  Are they greater than the benefits of a
format that is harder to parse, but easier for authors to write?

>
>>  Also, as has been pointed out before in the distributed extensibility
>> debate, parsing is a very small part of doing useful things with content.
>
> Yes. However many of the use cases that I think justify the inclusion of
> RDFa are already very small on their own, and valuable when several
> vocabularies are combined. So being able to do off-the-shelf parsing is
> valuable, compared to working out how to parse a combination of formats
> together.

Can you provide these use-cases?  The discussion has an astonishing
dearth of use-cases by which we can evaluate the effectiveness of
proposals.

>>> Secondly, as the result of having one single parsing algorithm,
>>> decentralised development is possible. If I want a way of marking up my
>>> iguana collection semantically, I can develop that vocabulary without
>>> having to go through a central authority.
>>
>> You can develop vocabularies without going through a central authority
>> already, via class or id, and many people already do.
>>
>>> Because URIs are used to
>>> identify vocabulary terms, I can be sure that my vocabulary won't clash
>>> with other people's vocabularies.
>>
>> Again, you can do this with class, by putting your domain name in the
>> class attribute.  It also depends on how much of an issue you think clashes
>> will be with an iguana collection-- I would suggest that due 

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

[Tab Atkins Jr.]

On Wed, Dec 31, 2008 at 10:41 PM, Charles McCathieNevile
 wrote:
> A standard way to include arbitrary data in a web page and extract it for
> machine processing, without having to pre-coordinate their data models.

This isn't a requirement (or in other words, a problem), it's a
solution.  What are the problems that need to be solved, and for which
having a standard way to include arbitrary data in a web page and have
it easily extractable would be helpful?  (Note:  I think there
certainly *are* problems that *would* find this helpful, I'm just
trying to lead your argument into the right direction.)  (As well,
since the discussion is about RDFa specifically, not data-markup in
general, what are the problems that need RDFa *specifically* as a
solution, as compared to the myriad other ways to embed data?)

> Since many people use RDF as an interchange, storage and processing format
> for this kind of data (because it provides for automated mapping of data
> from one schema to many others, without requiring anyone to touch the
> original schemata or agree in advance how they should be created), I believe
> there is a requirement for a method that allows third parties to include RDF
> data in, and extract it from information encoded within an HTML page.

Solutions for this already exist; embedded N3 in a 

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

[Benjamin Hawkes-Lewis]

On 2/1/09 10:38, Henri Sivonen wrote:

More to the point, Microformats not only require per-format processing
but the processing required for each Microformat isn't specified at all.
That's bad.


Some do have processing specified (at least to some degree):

http://microformats.org/wiki/hcard-parsing

For the rest, this seems like something fixable, so I'm not sure how 
this is more to the point?


> That is, have

there been attempts of defining unified parsing while retaining the feel
of Microformats without relying on the namespace mapping context from
the layer below?


I suppose -

* http://microformats.org/wiki/design-patterns (reusable microformat 
components)


* http://microformats.org/wiki/parsing-brainstorming (attempt to 
actually specify precise parsing rules for all microformats)


* 
http://microformats.org/discuss/mail/microformats-discuss/2008-August/012435.html 
(proposal for specifying generic mapping of microformats to RDF - I 
think there's been more detailed work by various parties in this regard, 
but I'm not sure where best to link to)


- are approaching this problem from three different angles.


Why hasn't the community fixed it?


I think the microformats community moves slowly, for better or worse, 
even when it agrees that there's a problem to solve. For example, 
progress on the problems with the abbr-design-pattern has been 
snail-like while losing the community an important user (the BBC), 
although admittedly the problems are basically intractable in HTML4/XHTML1.


I'm not sure how far the community as a whole does or doesn't view the 
lack of unified parsing as one of its bigger problems; I'm no spokesman 
though.



Is it a non-problem after all in practice?


It's an additional barrier to creating and using (especially new) 
microformats or other extractable patterns.


The microformats community isn't there to support the creation of new 
extractable patterns outside the microformats community, which is where 
an iguana database pattern would likely need to be.


It could of course be the RDFa curie is worse than the disease.

An advantage of RDFa that is not related to curies and for which the 
three approaches towards unified extraction mentioned above are not a 
substitute is that RDFa provides a generic way to include hidden 
machine-friendly equivalents to human-readable information in the form 
of the (not especially well-named) "content" attribute.


http://www.w3.org/TR/rdfa-syntax/#rdfa-attributes

In general, this is something microformats rightly try to avoid:

http://microformats.org/wiki/principles

But sometimes it's unavoidable:

http://microformats.org/wiki/machine-data

http://microformats.org/wiki/value-excerption-pattern-issues

I do not believe that HTML5 as currently specified would remove the need 
to employ similar hacks as are mentioned on those pages, although it 
will remove the need in many cases (e.g. for datetimes within a given 
range), which is an improvement.



Is the problem in the case of recipes that the provider of the page
navigation around the recipe is unwilling to license the navigation bits
under the same license as the content proper?


I thought Toby's example was that each recipe on the page needed a 
different licence, rather than a distinction between the main content 
area and the navigation.



In the case of images, why should a program inferring something about
licensing trust assertions made in a different HTTP resource (possibly
even from a different Origin)?


Why should it trust assertions made in the same resource?

For example, presumably you could download an image, change its 
licencing metadata, and host it at your own Origin? Admittedly, that's a 
little more work than just hotlinking.


--
Benjamin Hawkes-Lewis

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

[Henri Sivonen]

On Jan 1, 2009, at 06:41, Charles McCathieNevile wrote:

There are many cases where people build their own dataset and  
queries to solve a local problem. As an example, Opera is not  
intersted in asking Google to index data related to internal  
developer documents, and use it to produce further documentation we  
need. However, we do automatically extract various kinds of data  
from internal documents and re-use it. While Opera does not in fact  
use the RDF toolstack for that process, there are many other large  
companies and organisations who do, and who would benefit from being  
able to use RDFa in that process.


If the data production and consumption are both under the control of  
one entity (Opera in this case), why does the solution need to be  
engineered for spontaneous integration of decentralized data sources?


Do the savings of using off-the-shelf tools outweigh the cost they  
impose by not being quite right for any specific purpose? Presumably  
the Opera-specific processing is more significant than generic  
parsing. Or is it?


It seems that RDFa is motivated by private data and by interchange at  
the same time. This suggests multiple bilateral access control  
agreements instead of a Web-like system where data is made available  
for GETting without prior agreement between the parties.


--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

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

[Henri Sivonen]

On Jan 1, 2009, at 17:24, Toby A Inkster wrote:


So why RDFa and not Microformats?


There's a possibility that this is a false dichotomy and both are bad.

Firstly, RDFa provides a single unified parsing algorithm that  
Microformats do not. Separate parsers need to be created for  
hCalendar, hReview, hCard, etc, as each Microformat has its own  
unique parsing quirks. For example, hCard has N-optimisation and ORG- 
optimisation which aren't found in hCalendar. With RDFa, a single  
algorithm is used to parse everything: contacts, events, places,  
cars, songs, whatever.


More to the point, Microformats not only require per-format processing  
but the processing required for each Microformat isn't specified at  
all. That's bad.


RDFa, on the other hand, uses CURIEs, which is bad. (More generally, I  
think using URIs as identifiers instead of using them for above-TCP- 
layer protocol addressing is bad, but relying on the namespace mapping  
context is even worse.)


Have there been any attempts to remove the badness of Microformats  
without introducing the badness of RDFa in the process? That is, have  
there been attempts of defining unified parsing while retaining the  
feel of Microformats without relying on the namespace mapping context  
from the layer below?


If not, why not? I'm assuming that people in the Microformat community  
have clue. Yet, on the face of it, viewed from outside the community,  
their formats seem to have a big problem. Why hasn't the community  
fixed it? Is it a non-problem after all in practice?


Lastly, there are a lot of parsing ambiguities for many  
Microformats. One area which is especially fraught is that of  
scoping. The editors of many current draft Microformats[1] would  
like to allow page authors to embed licensing data - e.g. to say  
that a particular recipe for a pie is licensed under a Creative  
Commons licence. However, it has been noted that the current  
rel=license Microformat can not be re-used within these drafts,  
because virtually all existing rel=license implementations will just  
assume that the license applies to the whole page rather than just  
part of it. RDFa has strong and unambiguous rules for scoping - a  
license, for example, could apply to a section of the page, or one  
particular image.


Is the problem in the case of recipes that the provider of the page  
navigation around the recipe is unwilling to license the navigation  
bits under the same license as the content proper?


In the case of images, why should a program inferring something about  
licensing trust assertions made in a different HTTP resource (possibly  
even from a different Origin)?


--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

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

[Charles McCathieNevile]

On Fri, 02 Jan 2009 05:43:05 +1100, Andi Sidwell  wrote:


On 2009-01-01 15:24, Toby A Inkster wrote:
The use cases for RDFa are pretty much the same as those for  
Microformats.


Right, but microformats can be used without any changes to the HTML  
language, whereas RDFa requires such changes.  If they fulfill the same  
use cases, then there's not much point in adding RDFa.

...

So why RDFa and not Microformats?


(I think the question should be why RDFa is needed *as well as* µformats)


Firstly, RDFa provides a single unified parsing algorithm that
Microformats do not. ...


This is not necessarily beneficial.  If you have separate parsing  
algorithms, you can code in shortcuts for common use-cases and thus  
optimise the authoring experience.


On the other hand, you cannot parse information until you know how it is  
encoded, and information encoded in RDFa can be parsed without knowing  
more.


And not only can you optimise your parsing for a given algorithm, you can  
also do for a known vocabulary - or you can optimise the post-parsing  
treatment.


 Also, as has been pointed out before in the distributed extensibility  
debate, parsing is a very small part of doing useful things with content.


Yes. However many of the use cases that I think justify the inclusion of  
RDFa are already very small on their own, and valuable when several  
vocabularies are combined. So being able to do off-the-shelf parsing is  
valuable, compared to working out how to parse a combination of formats  
together.



Secondly, as the result of having one single parsing algorithm,
decentralised development is possible. If I want a way of marking up my
iguana collection semantically, I can develop that vocabulary without
having to go through a central authority.


You can develop vocabularies without going through a central authority  
already, via class or id, and many people already do.



Because URIs are used to
identify vocabulary terms, I can be sure that my vocabulary won't clash
with other people's vocabularies.


Again, you can do this with class, by putting your domain name in the  
class attribute.  It also depends on how much of an issue you think  
clashes will be with an iguana collection-- I would suggest that due to  
the specialised nature of the markup, clashes would be quite unlikely.


It depends how many people work on iguana collections - or Old Norse and  
Anglo Saxon text, which was the use case that got me involved in the Web  
in the very early 90s. It turns out that people don't, in the µformats  
world, use unambiguous names, especially when they are privately  
developing their own information. By contrast, those who come from an RDF  
world do this by habit.



It can be argued that going through a
community to develop vocabularies is beneficial, as it allows the
vocabulary to be built by "many minds" - RDFa does not prevent this, it
just gives people alternatives to community development.


RDFa does not give anything over what the class attribute does in terms  
of community vs individual development, so this doesn't really speak in  
RDFa's favour.


In principle no, but in real world usage the class attribute is considered  
something that is primarily local, whereas RDFa is generally used by  
people who have a broader outlook on the desirable permanence and  
re-usability of their data.



Lastly, there are a lot of parsing ambiguities for many Microformats.
One area which is especially fraught is that of scoping. The editors of
many current draft Microformats[1] would like to allow page authors to
embed licensing data - e.g. to say that a particular recipe for a pie is
licensed under a Creative Commons licence. However, it has been noted
that the current rel=license Microformat can not be re-used within these
drafts, because virtually all existing rel=license implementations will
just assume that the license applies to the whole page rather than just
part of it. RDFa has strong and unambiguous rules for scoping - a
license, for example, could apply to a section of the page, or one
particular image.


Are there other cases where this granularity of scoping would be  
genuinely helpful?  If not, it would seem better to work out a solution  
for scoping licence information...


Yes.

Being able to describe accessibility of various parts of content, or point  
to potential replacement content for particular use cases, benefits  
enormously from such scoping (this is why people who do industrial-scale  
accessibility often use RDF as their infrastructure). ARIA has already  
taken the approach of looking for a special-purpose way to do this, which  
significantly bloats HTML but at least allows important users to satisfy  
their needs to be able t produce content with certain information included.


Government and large enterprises produce content that needs to be  
maintained, and being able to include production, cataloguing, and similar  
metadata directly, scoped to the 

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

[Andi Sidwell]

On 2009-01-01 15:24, Toby A Inkster wrote:

The use cases for RDFa are pretty much the same as those for Microformats.


Right, but microformats can be used without any changes to the HTML 
language, whereas RDFa requires such changes.  If they fulfill the same 
use cases, then there's not much point in adding RDFa.



For example, if a person's name and contact details are marked up on a
web page using hCard, the user-agent can offer to, say, add the person
to your address book, or add them as a friend on a social networking
site, or add a reminder about that person's birthday to your calendar.

If an event is marked up on a web page using hCalendar, then the
user-agent could offer to add it to a calendar, or provide the user with
a map of its location, or add it to a timeline that the user is building
for their school history project.

Providing rich semantics for the information on a web page allows the
user-agent to know what's on a page, and step in and perform helpful
tasks for the user.

So why RDFa and not Microformats?

Firstly, RDFa provides a single unified parsing algorithm that
Microformats do not. Separate parsers need to be created for hCalendar,
hReview, hCard, etc, as each Microformat has its own unique parsing
quirks. For example, hCard has N-optimisation and ORG-optimisation which
aren't found in hCalendar. With RDFa, a single algorithm is used to
parse everything: contacts, events, places, cars, songs, whatever.


This is not necessarily beneficial.  If you have separate parsing 
algorithms, you can code in shortcuts for common use-cases and thus 
optimise the authoring experience.  Also, as has been pointed out before 
in the distributed extensibility debate, parsing is a very small part of 
doing useful things with content.



Secondly, as the result of having one single parsing algorithm,
decentralised development is possible. If I want a way of marking up my
iguana collection semantically, I can develop that vocabulary without
having to go through a central authority.


You can develop vocabularies without going through a central authority 
already, via class or id, and many people already do.



Because URIs are used to
identify vocabulary terms, I can be sure that my vocabulary won't clash
with other people's vocabularies.


Again, you can do this with class, by putting your domain name in the 
class attribute.  It also depends on how much of an issue you think 
clashes will be with an iguana collection-- I would suggest that due to 
the specialised nature of the markup, clashes would be quite unlikely.



It can be argued that going through a
community to develop vocabularies is beneficial, as it allows the
vocabulary to be built by "many minds" - RDFa does not prevent this, it
just gives people alternatives to community development.


RDFa does not give anything over what the class attribute does in terms 
of community vs individual development, so this doesn't really speak in 
RDFa's favour.



Lastly, there are a lot of parsing ambiguities for many Microformats.
One area which is especially fraught is that of scoping. The editors of
many current draft Microformats[1] would like to allow page authors to
embed licensing data - e.g. to say that a particular recipe for a pie is
licensed under a Creative Commons licence. However, it has been noted
that the current rel=license Microformat can not be re-used within these
drafts, because virtually all existing rel=license implementations will
just assume that the license applies to the whole page rather than just
part of it. RDFa has strong and unambiguous rules for scoping - a
license, for example, could apply to a section of the page, or one
particular image.


Are there other cases where this granularity of scoping would be 
genuinely helpful?  If not, it would seem better to work out a solution 
for scoping licence information instead of bringing in a whole new 
vocabulary to solve it.


What would you do with scoped copyright information, anyway?  I can see 
images being an issue, but ideally information about a resource should 
be kept in that resource, and as such the licence should be embedded in 
the image rather than given by a Web page.  In the case of particular 
sections having particular licences, is there any practical use of 
marking up different sections with different licences over just doing 
that with text?



RDFa was largely borne of looking at Microformats, looking at what was
successful about them, considering problems with them, and finding ways
to resolve those problems.


Andi

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

[Toby A Inkster]

The use cases for RDFa are pretty much the same as those for  
Microformats.


For example, if a person's name and contact details are marked up on  
a web page using hCard, the user-agent can offer to, say, add the  
person to your address book, or add them as a friend on a social  
networking site, or add a reminder about that person's birthday to  
your calendar.


If an event is marked up on a web page using hCalendar, then the user- 
agent could offer to add it to a calendar, or provide the user with a  
map of its location, or add it to a timeline that the user is  
building for their school history project.


Providing rich semantics for the information on a web page allows the  
user-agent to know what's on a page, and step in and perform helpful  
tasks for the user.


So why RDFa and not Microformats?

Firstly, RDFa provides a single unified parsing algorithm that  
Microformats do not. Separate parsers need to be created for  
hCalendar, hReview, hCard, etc, as each Microformat has its own  
unique parsing quirks. For example, hCard has N-optimisation and ORG- 
optimisation which aren't found in hCalendar. With RDFa, a single  
algorithm is used to parse everything: contacts, events, places,  
cars, songs, whatever.


Secondly, as the result of having one single parsing algorithm,  
decentralised development is possible. If I want a way of marking up  
my iguana collection semantically, I can develop that vocabulary  
without having to go through a central authority. Because URIs are  
used to identify vocabulary terms, I can be sure that my vocabulary  
won't clash with other people's vocabularies. It can be argued that  
going through a community to develop vocabularies is beneficial, as  
it allows the vocabulary to be built by "many minds" - RDFa does not  
prevent this, it just gives people alternatives to community  
development.


Lastly, there are a lot of parsing ambiguities for many Microformats.  
One area which is especially fraught is that of scoping. The editors  
of many current draft Microformats[1] would like to allow page  
authors to embed licensing data - e.g. to say that a particular  
recipe for a pie is licensed under a Creative Commons licence.  
However, it has been noted that the current rel=license Microformat  
can not be re-used within these drafts, because virtually all  
existing rel=license implementations will just assume that the  
license applies to the whole page rather than just part of it. RDFa  
has strong and unambiguous rules for scoping - a license, for  
example, could apply to a section of the page, or one particular image.


RDFa was largely borne of looking at Microformats, looking at what  
was successful about them, considering problems with them, and  
finding ways to resolve those problems.



1. It has been discussed in hAudio, figure, hRecipe and others.

--
Toby A Inkster

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

[Charles McCathieNevile]

Summary:

I believe that there are use cases for RDFa - and that they are precisely  
the sort of thing that Yahoo, Google, Ask, and their ilk are not going to  
be interested in, since they are based on solving problems that those  
search engines do not efficiently solve, such as (among others) using  
private data or dealing with trustworthy data to answer very specific  
questions automatically.


If Ian needs to understand the Semantic Web Industry and why people have  
invested in the RDFa proposal, then it is important to identify the right  
questions, and having him alone identify the sub-questions when he doesn't  
understand the issue isn't going to help him make a well-informed decision.


Some of Ian's questions are discussed here. I cut the mail "short" since I  
think it is already too long for many people, which means that the debate  
will simply pass without their reading or input.


On Wed, 31 Dec 2008 20:46:01 +1100, Ian Hickson  wrote:


One of the outstanding issues for HTML5 is the question of whether HTML5
should solve the problem that RDFa solves, e.g. by embedding RDFa

...

Before I can determine whether we should solve this problem, and before I
can evaluate proposals for solving this problem, I need to learn what the
problem is.

Earlier this year, there was a thread on RDFa on the WHATWG list. Very
little of the thread focused on describing the problem. This e-mail is an
attempt to work out what the problem is based on that feedback, on
discussions at the recent TPAC, and on other research I have done.


On Mon, 25 Aug 2008, Manu Sporny wrote:

Ian Hickson wrote:
> I have no idea what problem RDFa is trying to solve. I have no idea
> what the requirements are.

Web browsers currently do not understand the meaning behind human
statements or concepts on a web page. If web browsers could understand
that a particular page was describing a piece of music, a movie, an
event, a person or a product, the browser could then help the user find
more information about the particular item in question. It would help
automate the browsing experience. Not only would the browsing experience
be improved, but search engine indexing quality would be better due to a
spider's ability to understand the data on the page with more accuracy.


Let's see if I can rephrase that in terms of requirements.

* Web browsers should be able to help users find information related to
  the items that page they are looking at discusses.

* Search engines should be able to determine the contents of pages with
  more accuracy than today.

Is that right?

Are those the only requirements/problems that RDFa is attempting to
address? If not, what other requirements are there?


I don't think so. I think there are some other requirements:

A standard way to include arbitrary data in a web page and extract it for  
machine processing, without having to pre-coordinate their data models.


Since many people use RDF as an interchange, storage and processing format  
for this kind of data (because it provides for automated mapping of data  
from one schema to many others, without requiring anyone to touch the  
original schemata or agree in advance how they should be created), I  
believe there is a requirement for a method that allows third parties to  
include RDF data in, and extract it from information encoded within an  
HTML page.



The Microformats community has done a remarkable job of working on the
web semantics problem, creating several different methods of expressing
common human concepts (contact information (hCard), events (hCalendar),
and audio recordings (hAudio)).


Right; with Microformats, each Microformat has its own problem space and
thus each one can be evaluated separately. It is much harder to evaluate
something when the problem space is as generic as it appears RDFa's is.


The point is that there are a very large set of very small problem spaces  
relevant to a small group at a time. Like RDF itself, RDFa is meeting the  
problem of allowing these people to share machine-processable data without  
previously coordinating their approach.



The results of the first set of Microformats efforts were some pretty
cool applications, like the following one demonstrating how a web
browser could forward event information from your PC web browser to your
phone via Bluetooth:

http://www.youtube.com/watch?v=azoNnLoJi-4


It's a technically very interesting application. What has the adoption
rate been like? How does it compare to other solutions to the problem,
like CalDav, iCal, or Microsoft Exchange? Do people publish calendar
events much? There are a lot of Web-based calendar systems, like MobileMe
or WebCalendar. Do people expose data on their Web page that can be used
to import calendar data to these systems?


In some cases this data is indeed exposed to Webpages. However, anecdotal  
evidence (which unfortunately is all that is available when trying to  
study the enormous collections of data in private