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 sem
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,
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
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" example
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
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 the
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 e
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?
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. Nobo
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)
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
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://r
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
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 me
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
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
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 unlikel
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
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 othe
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
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 h
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
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,
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
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
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
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 S
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
> i
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 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
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 a
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
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 w
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 (
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 d
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 unwill
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 "
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.
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
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 le
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 t
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 whethe
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
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
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
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.
...
Personal
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 tes
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
Mic
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 gene
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
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?
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
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.
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
compelli
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
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 o
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.
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
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
Tab Atkins Jr. wrote:
...
Solutions for this already exist; embedded N3 in a
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
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
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-pars
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
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, h
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.
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 po
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 sit
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)
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
70 matches
Mail list logo
