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
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
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,
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?
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
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).
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.
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
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)
On Sat, 10 Jan 2009 06:41:10 +1100, Julian Reschke julian.resc...@gmx.de
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
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
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
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 link rel=alternate
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 link
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
On Fri, Jan 9, 2009 at 5:46 AM, Julian Reschke julian.resc...@gmx.de 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
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
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
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,
On Fri, Jan 9, 2009 at 1:48 PM, Ben Adida b...@adida.net 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
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
On Fri, Jan 9, 2009 at 2:17 PM, Ben Adida b...@adida.net 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
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
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,
On Fri, Jan 9, 2009 at 3:22 PM, Ben Adida b...@adida.net 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,
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 title, which is clearly
featured in search engine results?
-Ben
On Fri, Jan 9, 2009 at 5:13 PM, Ben Adida b...@adida.net 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 title, which is clearly
featured in search engine
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
Tab Atkins Jr. wrote:
To answer your specific question, title 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
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
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
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
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
Charles McCathieNevile ha scritto:
On Sun, 04 Jan 2009 03:51:53 +1100, Calogero Alex Baldacchino
alex.baldacch...@email.it wrote:
Charles McCathieNevile ha scritto:
... it shouldn't be too difficoult to create a custom parser,
comforming to RDFa spec and availing of data-* attributes...
Charles McCathieNevile ha scritto:
On Mon, 05 Jan 2009 01:21:33 +1100, Henri Sivonen hsivo...@iki.fi
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
On Mon, 05 Jan 2009 00:17:39 +1100, Henri Sivonen hsivo...@iki.fi 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
On Sun, 04 Jan 2009 16:37:08 +1100, timeless timel...@gmail.com wrote:
On Sun, Jan 4, 2009 at 3:49 AM, Charles McCathieNevile
cha...@opera.com 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
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
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
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
On Mon, 05 Jan 2009 01:21:33 +1100, Henri Sivonen hsivo...@iki.fi 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
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
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
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
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.
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
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:
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
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
On Sat, 03 Jan 2009 04:52:35 +1100, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Fri, Jan 2, 2009 at 12:12 AM, Charles McCathieNevile
cha...@opera.com wrote:
On Fri, 02 Jan 2009 05:43:05 +1100, Andi Sidwell a...@takkaria.org
wrote:
On 2009-01-01 15:24, Toby A Inkster wrote:
The use
On Sun, 04 Jan 2009 03:51:53 +1100, Calogero Alex Baldacchino
alex.baldacch...@email.it wrote:
Charles McCathieNevile ha scritto:
... it shouldn't be too difficoult to create a custom parser, comforming
to RDFa spec and availing of data-* attributes...
That is, since RDFa can be emulated
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
On Sun, Jan 4, 2009 at 3:49 AM, Charles McCathieNevile cha...@opera.com 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
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,
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
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):
On Wed, Dec 31, 2008 at 10:41 PM, Charles McCathieNevile
cha...@opera.com 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
On Fri, Jan 2, 2009 at 12:12 AM, Charles McCathieNevile
cha...@opera.com wrote:
On Fri, 02 Jan 2009 05:43:05 +1100, Andi Sidwell a...@takkaria.org 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
Tab Atkins Jr. wrote:
...
Solutions for this already exist; embedded N3 in a script tag, just
to name something that Ian already mentioned, allows you to mash RDF
data into a page in a machine-extractable way, and brings in any of
the specific ancillary benefits of RDF.
...
Well, it'll require
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
On Fri, Jan 2, 2009 at 11:55 AM, Julian Reschke julian.resc...@gmx.de wrote:
Tab Atkins Jr. wrote:
...
Solutions for this already exist; embedded N3 in a script tag, just
to name something that Ian already mentioned, allows you to mash RDF
data into a page in a machine-extractable way, and
On Fri, Jan 2, 2009 at 12:02 PM, Julian Reschke julian.resc...@gmx.de 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
On Fri, 02 Jan 2009 05:43:05 +1100, Andi Sidwell a...@takkaria.org 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
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 straight
into HTML5, or by some other method.
Before I can determine whether we should solve this problem, and before I
can evaluate proposals for solving
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)
65 matches
Mail list logo
