Re: [whatwg] [Fwd: Re: Helping people seaching for content filtered by license]

2009-05-14 Thread Smylers
Nils Dagsson Moskopp writes:

> Am Freitag, den 08.05.2009, 19:57 + schrieb Ian Hickson:
> 
> >  * Tara runs a video sharing web site for people who want
> >licensing information to be included with their videos. When
> >Paul wants to blog about a video, he can paste a fragment of
> >HTML provided by Tara directly into his blog. The video is
> >then available inline in his blog, along with any licensing
> >information about the video.
> > 
> > This can be done with HTML5 today. For example, here is the markup you 
> > could include to allow someone to embed a video on their site while 
> > including the copyright or license information:
> > 
> >
> > http://example.com/videodata/sJf-ulirNRk"; controls>
> >  http://video.example.com/watch?v=sJf-ulirNRk";>Watch
> > 
> > 
> >  Pillar post surgery, starting to heal.
> >  © copyright 2008 Pillar. All Rights Reserved.
> > 
> >
> 
> Seriously, I don't get it. Is there really so much entrenched (widely
> deployed, a mess, IE-style) software out there relying on @rel=license
> meaning "license of a single main content blob"

Merely using rel=license in the above example would not cause the
copyright message to be displayed to users.

> that an unambigous (read: machine-readable) writeup of part licenses
> is impossible ?

Why does the license information need to be machine-readable in this
case?  (It may need to be for a different scenario, but that would be
dealt with separately.)

> > The example above shows this for a movie, but it works as well for a
> > photo:
> > 
> >
> >  http://nearimpossible.com/DSCF0070-1-tm.jpg"; alt="">
> >  
> >   Picture by Bob.
> >> href="http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode";>Creative 
> >   Commons Attribution-Noncommercial-Share Alike 2.5 Generic 
> > License
> >  
> >
> 
> Can I infer from this that an  in a  inside a  is
> some kind of microformat for licensing information ?

No.  But if a human sees a string that mentions "© copyright" or
"license" then she's likely to realize it's licencing information.  And
if it's placed next to a picture it's conventional to interpret that as
applying to a picture.  It's also conventional for such information to
be small, because it's usually not the main content the user is
interested in when choosing to view the page.

Magazines and the like have been using this convention for years,
without any need to explicitly define what indicates licensing
information, seemingly without any ambiguity or confusion.

Smylers


Re: [whatwg] Annotating structured data that HTML has no semantics for

2009-05-14 Thread Maciej Stachowiak


On May 14, 2009, at 1:30 PM, Shelley Powers wrote:

So, if I'm pushing for RDFa, it's not because I want to "win". It's  
because I have things I want to do now, and I would like to make  
sure have a reasonable chance of working a couple of years in the  
future. And yeah, once SVG is in HTML5, and RDFa can work with  
HTML5, maybe I wouldn't mind giving old HTML a try again. Lord knows  
I'd like to user ampersands again.


It sounds like your argument comes down to this: you have personally  
invested in RDFa, therefore having a competing technology is bad,  
regardless of the technical merits. I don't mean to parody here - I am  
somewhat sympathetic to this line of argument. Often pragmatic  
concerns mean that an incremental improvement just isn't worth the  
cost of switching (for example HTML vs. XHTML). My personally judgment  
is that we're not past the point of no return on data embedding.  
There's microformats, RDFa, and then dozens of other serializations of  
RDF (some of which you cited). This doesn't seem like a space on the  
verge of picking a single winner, and the players seem willing to  
experiment with different options.






The point is, people in the real world have to use this stuff. It  
helps them if they have one, generally agreed on approach. As it  
is, folks have to contend with both RDFa and microformats, but at  
least we know these have different purposes.


From my cursory study, I think microdata could subsume many of the  
use cases of both microformats and RDFa. It seems to me that it  
avoids much of what microformats advocates find objectionable, and  
provides a good basis for new microformats; but at the same time it  
seems it can represent a full RDF data model. Thus, I think we have  
the potential to get one solution that works for everyone.


I'm not 100% sure microdata can really achieve this, but I think  
making the attempt is a positive step.



It can't, don't you see?

Microdata will only work in HTML5/XHTML5. XHTML 1.1 and yes, 2.0  
will be around for years, decades. In addition, XHTML5 already  
supports RDFa.


Supporting XHTML 1.1 has about 0.001% as much value as  
supporting  text/html. XHTML 2.0 is completely irrelevant to the Web,  
and looks on track to remain so. So I don't find this point very  
persuasive.


Why you think something completely brand new, no vendor support,  
drummed up in a few hours or a day or so is more robust, and a  
better option than a mature spec in wide use, well frankly boggles  
my mind.


I haven't evaluated it enough to know for sure (as I said). I do think  
avoiding CURIEs is extremely valuable from the point of view of sane  
text/html semantics and ease of authoring; and RDF experts seem to  
think it works fine for representing RDF data models. So tentatively,  
I don't see any gaping holes. If you see a technical problem, and not  
just potential competition for the technology you've invested in, then  
you should definitely cite it.




I am impressed with your belief in HTML5.

But
One other detail that it seems not many people have picked up on  
yet is that microdata proposes a DOM API to extract microdata-based  
info from a live document on the client side. In my opinion this is  
huge and has the potential to greatly increase author interest in  
semantic markup.




Not really. Can do this now with RDFa in XHTML. And I don't need any  
new DOM to do it.


The power of semantic markup isn't really seen until you take that  
markup data _outside_ the document. And merge that data with data  
from other documents. Google rich snippets. Yahoo searchmonkey.  
Heck, even an application that manages the data from different  
subsites of one domain.


I respectfully disagree. An API to do things client-side that doesn't  
require an external library is extremely powerful, because it lets  
content authors easily make use of the very same semantic markup that  
they are vending for third parties, so they have more incentive to use  
it and get it right.




Now, it may be that microdata will ultimately fail, either because  
it is outcompeted by RDFa, or because not enough people care about  
semantic markup, or whatever. But at least for now, I don't see a  
reason to strangle it in the cradle.




Outcompeted...wow, what a way to think of it. Sorry, but competition  
has no place in spec work.


With due respect, you're the one who brought competition into this  
discussion by saying there can only be one winner. I don't really  
think that's true, in this case.


Regards,
Maciej



Re: [whatwg] Annotating structured data that HTML has no semantics for

2009-05-14 Thread Philip Taylor
On Thu, May 14, 2009 at 2:54 PM, Philip Taylor  wrote:
> [...]
>    _:X .
> [...]
>  
>    
>    
>  
> [...]
> So, I can't see any limits on expressivity other than that literals
> must be strings.

Hmm, I think I'm wrong here. 'id' has to be unique, which means this
pattern won't work if _:X is the object for triples with two different
subjects.

Additionally, there must be a chain from every blank node back to <>
via , else it won't get
serialised (since serialisation starts from top-level items and
recurses down the correspondence chains). As a consequence of this and
the previous point, it is impossible to express cycles (e.g. "_:X
 _:X", or any longer cycles) unless the cycle contains
<>.

So there are these two restrictions on the shapes of expressible RDF
graphs. (I can't think of any other restrictions, though...)

-- 
Philip Taylor
exc...@gmail.com


Re: [whatwg] Annotating structured data that HTML has no semantics for

2009-05-14 Thread Jonas Sicking
On Thu, May 14, 2009 at 5:00 PM, Jonas Sicking  wrote:
> * Support for specifying a machine-readable value, such as for dates,
> colors, numbers, etc.
> * Support for tabular data.
>
> Especially the former is very interesting to me. I even wonder it
> would allow replacing the  element with a standardized
> microformat, such as:
>
> Christmas is going down on  itemvalue="12-25-2009">The 25th day of December!
>
> (Though I'd probably avoid prefixes for 'standardized' item names).

Hmm.. I guess the syntax would be



Not very nice I admit.

/ Jonas


Re: [whatwg] Annotating structured data that HTML has no semantics for

2009-05-14 Thread Jonas Sicking
In short, this proposal looks very interesting to me. There are
several things that attract me to it:

* Looks very simple to author
  This is absolutely critical to any web technology and IMHO where RDFa fails.
* Generic syntax which allows creations of generic parsers
  This will allow us to create APIs that expose microdata in a parsed
form to extensions which should significantly improve the amount of
microdata support we can supply in Firefox.
  This will hopefully also allow integration of microdata with things
like the DOM and (CSS) Selectors.
* Separation of microdata from transitionally author "owned"
locations, such as the class attribute.
  This means we'll have to worry much less about accidental collisions
with author values.

Some of the improvement suggestions that I have heard that sounds
interesting, though possibly for the next version of microdata.

* Support for specifying a machine-readable value, such as for dates,
colors, numbers, etc.
* Support for tabular data.

Especially the former is very interesting to me. I even wonder it
would allow replacing the  element with a standardized
microformat, such as:

Christmas is going down on The 25th day of December!

(Though I'd probably avoid prefixes for 'standardized' item names).

/ Jonas


[whatwg] [Fwd: Re: Helping people seaching for content filtered by license]

2009-05-14 Thread Nils Dagsson Moskopp
sorry, forgot to cc the list

 Weitergeleitete Nachricht 
> Von: Nils Dagsson Moskopp
> 
> An: Ian Hickson 
> Betreff: Re: [whatwg] Helping people seaching for content filtered by
> license
> Datum: Mon, 11 May 2009 10:04:41 +0200
> 
> Am Freitag, den 08.05.2009, 19:57 + schrieb Ian Hickson:
> >  * Tara runs a video sharing web site for people who want licensing
> >information to be included with their videos. When Paul wants to blog
> >about a video, he can paste a fragment of HTML provided by Tara
> >directly into his blog. The video is then available inline in his
> >blog, along with any licensing information about the video.
> > 
> > (Really? A video sharing site dedicated to people who want licensing 
> > information to be included with their videos? That's a pretty specific 
> > audience, wow.)
> > 
> > This can be done with HTML5 today. For example, here is the markup you 
> > could include to allow someone to embed a video on their site while 
> > including the copyright or license information:
> > 
> >
> > http://example.com/videodata/sJf-ulirNRk"; controls>
> >  http://video.example.com/watch?v=sJf-ulirNRk";>Watch
> > 
> > 
> >  Pillar post surgery, starting to heal.
> >  © copyright 2008 Pillar. All Rights Reserved.
> > 
> >
> 
> Seriously, I don't get it. Is there really so much entrenched (widely
> deployed, a mess, IE-style) software out there relying on @rel=license
> meaning "license of a single main content blob" that an unambigous
> (read: machine-readable) writeup of part licenses is impossible ? How
> about a possible future keyword, say @rel=content-license ?
> 
> > The example above shows this for a movie, but it works as well for a 
> > photo:
> > 
> >
> >  http://nearimpossible.com/DSCF0070-1-tm.jpg"; alt="">
> >  
> >   Picture by Bob.
> >> href="http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode";>Creative 
> >   Commons Attribution-Noncommercial-Share Alike 2.5 Generic 
> > License
> >  
> >
> 
> Can I infer from this that an  in a  inside a  is some
> kind of microformat for licensing information ? Crude, if you really
> mean it this way, but probably workable. Maybe this needs to be
> explicitely spelled out in the spec ?
> 
> > Admittedly, if this scenario is taken in the context of the first 
> > scenario, meaning that Bob wants this image to be discoverable through 
> > search, but doesn't want to include it on a page of its own, then extra 
> > syntax to mark this particular image up would be useful.
> > 
> > However, in my research I found very few such cases. In every case where I 
> > found multiple media items on a single page with no dedicated page, either 
> > every item was licensed identically and was the main content of the page, 
> > or each item had its own separate page, or the items were licensed under 
> > the same license as the page. In all three of these cases, rel=license 
> > already solves the problem today.
> 
> Relying on linked pages just to get licensing information would be,
> well, massive overhead. Still, you are right - most blogs using many
> pictures have dedicated pages.
> 
> > This discourages people from using 
> > multiple licenses, of course, but that's actually a good thing, as it 
> > discourages license proliferation.
> 
> Actually, it discourages working along with perfectly good existing
> licenses as well. Like having CC-BY content on a CC-BY-SA site.
> 
> >  * Fred's browser can tell him what license a particular video on a site
> >he is reading has been released under, and advise him on what the
> >associated permissions and restrictions are (can he redistribute this
> >work for commercial purposes, can he distribute a modified version of
> >this work, how should he assign credit to the original author, what
> >jurisdiction the license assumes, whether the license allows the work
> >to be embedded into a work that uses content under various other
> >licenses, etc).
> > 
> > Advising a user on the legal implications of a license is something that 
> > needs trained professionals, but given a particular license, advice could 
> > be provided in canned form. So it seems like this is already possible, the 
> > user just has to select a license from a list of licenses. A user agent 
> > could pre-select a license based on the value of the page's rel=license 
> > link(s), or based on scanning the page for mention of a license, too.
> 
> AFAIK, the CC namespace exists for this purpose and answers some fairly 
> standard questions.
> 
> >  * When licensing a subpart of the page, existing implementations must
> >not just assume that the license applies to the whole page rather 
> > than
> >just part of it.
> > 
> > This is resolved by not having a mechanism for machine-readably licensing 
> > just part of a page, and instead put

Re: [whatwg] DOMTokenList is unordered but yet requires sorting

2009-05-14 Thread Erik Arvidsson
On Thu, May 14, 2009 at 00:30, Kristof Zelechovski
 wrote:
> If a token list represented an ordered set, it could not be sorted to get an
> item because the host would have to preserve the original (document) order
> of tokens.

The question is why does the set need to be ordered at all as long as
it is stable between changes? It would make implementations more
efficient with little no no loss in functionality.

-- 
erik


Re: [whatwg] Annotating structured data that HTML has no semantics for

2009-05-14 Thread Eduard Pascual
On Thu, May 14, 2009 at 3:54 PM, Philip Taylor  wrote:
> [...]
> If we restrict literals to strings [...]
But *why* restrict literals to strings?? Being unable to state that
"2009-05-14" is a date makes that value completely useless: it would
only be useful on contexts where a date is expected (bascially,
because it is a date), but it can't be used on such contexts because
the tool retrieving the value has no hint about it being a date. Same
is true for integers, prices (a.k.a. decimals plus a currency symbol),
geographic coordinates, iguana descriptions, and so on.

On Thu, May 14, 2009 at 8:25 PM, Maciej Stachowiak  wrote:
>
> On May 14, 2009, at 5:18 AM, Shelley Powers wrote:
>
>> So much concern about generating RDF, makes one wonder why we didn't just
>> implement RDFa...
>
> If it's possible to produce RDF triples from microdata, and if RDF triples
> of interest can be expressed with microdata, why does it matter if the
> concrete syntax is the same as RDFa? Isn't the important thing about RDF the
> data model, not the surface syntax?
It doesn't matter one syntax or another. But if a syntax already
exists (RDFa), building a new syntax should be properly justified. As
of now, the only supposed benefit I have heard of for this syntax is
that it avoids CURIEs... yet it replaces them with reversed domains??
Is that a benefit? I have been a Java programmer for some years, and
still find that convention absurd, horrible, and annoying. I'll agree
that CURIEs are ugly, and maybe hard to understand, but reversed
domains are equally ugly and hard to understand.

> (I understand that if the microdata syntax offered no advantages over RDFa,
> then it would be a wasted effort to diverge.
Which are the advantages it offers? I asked about them yesterday, and
no one has answered, so I'm asking again: please, enlighten me on this
because if I see no advantages myself and nobody else tells me about
any advantage, then the only conclusion a rational mind can take is
that there are no advantages. So, that's the position I'm on. I can
easily change my mind if anyone points out some advantage that might
actually help me more than RDFa when trying to add semantics and
metadata to my pages.

> But my impression is that you'd
> object to anything that isn't exactly identical to RDFa, even if it can
> easily be used in the same way.)
Actually, I do object to RDFa itself. Since the very first moment I
saw discussions about it on these lists, I have been trying to
highlight its flaws and to suggest ideas for alternatives.
Now, would you really expect me not to object to what, at least from
my current PoV, is simply worse than RDFa? IMHO, RDFa is just
*passable*, and microdata is too *mediocre* to get a pass. I don't
know about any solution that would be perfect, but I really think that
this community is definitely capable of producing something that is,
at least, *good*.

Of course, these are just my opinions, but I have told also what they
are based in. I'm eager to change my mind of there is base for it.

Regards,
Eduard Pascual


Re: [whatwg] Annotating structured data that HTML has no semantics for

2009-05-14 Thread Shelley Powers

Maciej Stachowiak wrote:


On May 14, 2009, at 1:04 PM, Shelley Powers wrote:


Maciej Stachowiak wrote:


On May 14, 2009, at 5:18 AM, Shelley Powers wrote:

So much concern about generating RDF, makes one wonder why we 
didn't just implement RDFa...


If it's possible to produce RDF triples from microdata, and if RDF 
triples of interest can be expressed with microdata, why does it 
matter if the concrete syntax is the same as RDFa? Isn't the 
important thing about RDF the data model, not the surface syntax?


(I understand that if the microdata syntax offered no advantages 
over RDFa, then it would be a wasted effort to diverge. But my 
impression is that you'd object to anything that isn't exactly 
identical to RDFa, even if it can easily be used in the same way.)


Regards,
Maciej


Because one would assume that one way to accomplish a task would be 
more attractive to web developers, designers, parser developers, 
browsers, et al.


In addition, one would also assume that one way to accomplish a task 
would be more attractive in regards to testing, maintaining and 
moving on in the future.


Notice how there is only VHS and not Betamax?

Notice the same about Blu-Ray and HD-TV? People won't buy into 
something while there are competitive specs, and these are 
"competitive" in that it makes little since to use both in a 
document, though you can now.


Physical media do tend to converge due to network effects. I think the 
effect is less strong for digital file formats. For example, MP3 and 
AAC are both fairly successful; similarly, MPEG-4, Windows Media and 
Ogg are all getting some degree of traction. But you may be right that 
ultimately there will be only one winner.


Now, that's the problem with all of this effort...winners and losers.

I don't support a spec because it gives me grins and giggles. I have 
certain tasks I want to do, and I look for what is the technology that 
has the most support in order to do them.


I've long been an adherent to RDF, which isn't really up for debate. 
Originally, I was an RDF/XML person, until the RDF-in-XHTML folks 
changed my mind.


What I see of RDFa is a specification that has been through a very long 
period of time, testing, commenting, being implemented by major players. 
I also have tools, right now, that I can use to process the RDFa, as 
well as support by two major search engine companies.


As Dan pointed out earlier, microdata seems to support most of RDF. 
Well, I know that RDFa does. It makes little sense to me to start from 
scratch when a mature specification with multi-vendor support already 
exists.


Especially when Drupal 7 rolls out with RDFa baked in. That's 1.7 
million sites supporting the spec. Then there's the new Google snippet 
thing -- who knows how many additional sites we'll now find supporting RDFa.


So, if I'm pushing for RDFa, it's not because I want to "win". It's 
because I have things I want to do now, and I would like to make sure 
have a reasonable chance of working a couple of years in the future. And 
yeah, once SVG is in HTML5, and RDFa can work with HTML5, maybe I 
wouldn't mind giving old HTML a try again. Lord knows I'd like to user 
ampersands again.




The point is, people in the real world have to use this stuff. It 
helps them if they have one, generally agreed on approach. As it is, 
folks have to contend with both RDFa and microformats, but at least 
we know these have different purposes.


From my cursory study, I think microdata could subsume many of the use 
cases of both microformats and RDFa. It seems to me that it avoids 
much of what microformats advocates find objectionable, and provides a 
good basis for new microformats; but at the same time it seems it can 
represent a full RDF data model. Thus, I think we have the potential 
to get one solution that works for everyone.


I'm not 100% sure microdata can really achieve this, but I think 
making the attempt is a positive step.



It can't, don't you see?

Microdata will only work in HTML5/XHTML5. XHTML 1.1 and yes, 2.0 will be 
around for years, decades. In addition, XHTML5 already supports RDFa.


Why you think something completely brand new, no vendor support, drummed 
up in a few hours or a day or so is more robust, and a better option 
than a mature spec in wide use, well frankly boggles my mind.


I am impressed with your belief in HTML5.

But
One other detail that it seems not many people have picked up on yet 
is that microdata proposes a DOM API to extract microdata-based info 
from a live document on the client side. In my opinion this is huge 
and has the potential to greatly increase author interest in semantic 
markup.




Not really. Can do this now with RDFa in XHTML. And I don't need any new 
DOM to do it.


The power of semantic markup isn't really seen until you take that 
markup data _outside_ the document. And merge that data with data from 
other documents. Google rich snippets. Yahoo searchmonkey. Heck, even an 
application

Re: [whatwg] Annotating structured data that HTML has no semantics for

2009-05-14 Thread Maciej Stachowiak


On May 14, 2009, at 1:04 PM, Shelley Powers wrote:


Maciej Stachowiak wrote:


On May 14, 2009, at 5:18 AM, Shelley Powers wrote:

So much concern about generating RDF, makes one wonder why we  
didn't just implement RDFa...


If it's possible to produce RDF triples from microdata, and if RDF  
triples of interest can be expressed with microdata, why does it  
matter if the concrete syntax is the same as RDFa? Isn't the  
important thing about RDF the data model, not the surface syntax?


(I understand that if the microdata syntax offered no advantages  
over RDFa, then it would be a wasted effort to diverge. But my  
impression is that you'd object to anything that isn't exactly  
identical to RDFa, even if it can easily be used in the same way.)


Regards,
Maciej


Because one would assume that one way to accomplish a task would be  
more attractive to web developers, designers, parser developers,  
browsers, et al.


In addition, one would also assume that one way to accomplish a task  
would be more attractive in regards to testing, maintaining and  
moving on in the future.


Notice how there is only VHS and not Betamax?

Notice the same about Blu-Ray and HD-TV? People won't buy into  
something while there are competitive specs, and these are  
"competitive" in that it makes little since to use both in a  
document, though you can now.


Physical media do tend to converge due to network effects. I think the  
effect is less strong for digital file formats. For example, MP3 and  
AAC are both fairly successful; similarly, MPEG-4, Windows Media and  
Ogg are all getting some degree of traction. But you may be right that  
ultimately there will be only one winner.


The point is, people in the real world have to use this stuff. It  
helps them if they have one, generally agreed on approach. As it is,  
folks have to contend with both RDFa and microformats, but at least  
we know these have different purposes.


From my cursory study, I think microdata could subsume many of the  
use cases of both microformats and RDFa. It seems to me that it avoids  
much of what microformats advocates find objectionable, and provides a  
good basis for new microformats; but at the same time it seems it can  
represent a full RDF data model. Thus, I think we have the potential  
to get one solution that works for everyone.


I'm not 100% sure microdata can really achieve this, but I think  
making the attempt is a positive step.


One other detail that it seems not many people have picked up on yet  
is that microdata proposes a DOM API to extract microdata-based info  
from a live document on the client side. In my opinion this is huge  
and has the potential to greatly increase author interest in semantic  
markup.


Now, it may be that microdata will ultimately fail, either because it  
is outcompeted by RDFa, or because not enough people care about  
semantic markup, or whatever. But at least for now, I don't see a  
reason to strangle it in the cradle.


Regards,
Maciej



Re: [whatwg] Annotating structured data that HTML has no semantics for

2009-05-14 Thread Shelley Powers

Maciej Stachowiak wrote:


On May 14, 2009, at 5:18 AM, Shelley Powers wrote:

So much concern about generating RDF, makes one wonder why we didn't 
just implement RDFa...


If it's possible to produce RDF triples from microdata, and if RDF 
triples of interest can be expressed with microdata, why does it 
matter if the concrete syntax is the same as RDFa? Isn't the important 
thing about RDF the data model, not the surface syntax?


(I understand that if the microdata syntax offered no advantages over 
RDFa, then it would be a wasted effort to diverge. But my impression 
is that you'd object to anything that isn't exactly identical to RDFa, 
even if it can easily be used in the same way.)


Regards,
Maciej


Because one would assume that one way to accomplish a task would be more 
attractive to web developers, designers, parser developers, browsers, et 
al.


In addition, one would also assume that one way to accomplish a task 
would be more attractive in regards to testing, maintaining and moving 
on in the future.


Notice how there is only VHS and not Betamax?

Notice the same about Blu-Ray and HD-TV? People won't buy into something 
while there are competitive specs, and these are "competitive" in that 
it makes little since to use both in a document, though you can now.


The point is, people in the real world have to use this stuff. It helps 
them if they have one, generally agreed on approach. As it is, folks 
have to contend with both RDFa and microformats, but at least we know 
these have different purposes.


Shelley


Re: [whatwg] / feedback

2009-05-14 Thread Jonas Sicking
On Tue, May 12, 2009 at 9:29 PM, David Singer  wrote:
> At 12:09  +1000 13/05/09, Silvia Pfeiffer wrote:
>>
>> On Wed, May 13, 2009 at 5:01 AM, Jonas Sicking  wrote:
>>>
>>>  On Sun, May 10, 2009 at 6:56 PM, David Singer  wrote:

  At 14:09  +1000 9/05/09, Silvia Pfeiffer wrote:
>
>  Of course none of the
>  discussion will inherently disallow seeking - scripts will always be
>  able to do the seeking. But the user may not find it easy to do
>  seeking to a section that is not accessible through the displayed
>  timeline, which can be both a good and a bad thing.

  How easy a particular user interface is to use for various tasks is (I
 hope)
  not our worry...
>>>
>>>  I'm not sure I agree. If the spec provides a feature set that no one
>>>  is able to create a useful UI for, then there definitely might be a
>>>  problem with the spec.
>>>
>>>  I still have not received any comments on my previous assertion that
>>>  there are essentially two separate use cases here. One for bringing
>>>  attention to a specific point in a larger context, one for showing
>>>  only a smaller range of a video.
>>
>> Just to confirm: yes, there are two separate use cases. (I was under
>> the impression that the discussion had brought that out).
>
> Yes, that's fine.  I think it's clear that we could have a 'verb' in the
> fragment "focus-on", "select" etc. to indicate that.  I think it's also
> clear that no matter what verb is used, the entire resource is 'available'
> to the UA, that scripts can (if they wish) navigate anywhere in the entire
> resource, and that UAs can optimize the interface for the given verb, but
> the interface can still permit access to the entire resource.

Personally I'm pretty un-opinionated on these details.

If setting a range in the fragment results in the .currentTime
spanning from 0 to length-of-range or from start-of-range to
end-or-range seems only like a question of which API is the most
author friendly. Script can always remove the range-fragment if it
wants to use a .currentTime outside of the range.

The only argument that I can think of either way is that it might be
hard to create a decent UI for the situation when a range is
specified, but .currentTime is set to outside that range using script.

But again, I don't have much of an opinion.

/ Jonas


Re: [whatwg] Annotating structured data that HTML has no semantics for

2009-05-14 Thread Maciej Stachowiak


On May 14, 2009, at 5:18 AM, Shelley Powers wrote:

So much concern about generating RDF, makes one wonder why we didn't  
just implement RDFa...


If it's possible to produce RDF triples from microdata, and if RDF  
triples of interest can be expressed with microdata, why does it  
matter if the concrete syntax is the same as RDFa? Isn't the important  
thing about RDF the data model, not the surface syntax?


(I understand that if the microdata syntax offered no advantages over  
RDFa, then it would be a wasted effort to diverge. But my impression  
is that you'd object to anything that isn't exactly identical to RDFa,  
even if it can easily be used in the same way.)


Regards,
Maciej



[whatwg] A Selector-based metadata proposal (was: Annotating structured data that HTML has no semantics for)

2009-05-14 Thread Eduard Pascual
I have put online a document that describes my idea/proposal for a
selector-based solution to metadata.
The document can be found at http://herenvardo.googlepages.com/CRDF.pdf
Feel free to copy and/or link the file wherever you deem appropriate.

Needless to say, feedback and constructive criticism to the proposal
is always welcome.
(Note: if discussion about this proposal should take place somewhere
else, please let me know.)

Regards,
Eduard Pascual


Re: [whatwg] Annotating structured data that HTML has no semantics for

2009-05-14 Thread Philip Taylor
On Thu, May 14, 2009 at 1:25 PM, Dan Brickley  wrote:
> Having HTML5-microdata -to- RDF parsers is pretty critical to having test
> cases that help us all understand where RDFa-Classic and HTML5 diverge. I'm
> very happy to see this work being done and that there are multiple
> implementations.
>
> As far as I can see, the main point of divergence is around URI abbreviation
> mechanisms. But also HTML5 might not have a notion equivalent to RDF/RDFa's
> bNodes construct. The sooner we have these parsers the sooner we'll know for
> sure.

If I understand RDF correctly, the idea is that everything can be
URIs, subjects and objects can instead be blank nodes, and objects can
instead be literals. If we restrict literals to strings (optionally
with languages), then I think all triples must follow one of these
eight patterns:

 .
"object" .
"object"@lang .
_:X .
  _:X   .
  _:X  "object" .
  _:X  "object"@lang .
  _:X  _:Y .

These cases can be trivially mapped into HTML5 microdata as:

  


  

  


  

  


  

  


  

  

  

  

  

(There's the caveat about  and  being moved into  in
some browsers; you can replace them with  and  instead.)

These aren't the most elegant ways of expressing complex structures
(because they don't make much use of nesting), but hopefully they
demonstrate that it's possible to express any RDF graph (that only
uses string literals) by decomposing into triples and then writing as
HTML with these patterns.

(If all the triples using a blank node have the same subject, then you
don't need to use 'id' and 'subject' because you can just nest the
markup instead, I think.)

With my parser (in Firefox 3.0), the output triples (sorted into a
clearer order) are:

  <>   .
  <>   .
  <>   .
  <>   .
 .
"object" .
"object"@lang .
_:n0 .
  _:n0   .
  _:n0  "object" .
  _:n0  "object"@lang .
  _:n0  _:n1 .

which corresponds to what was desired.

So, I can't see any limits on expressivity other than that literals
must be strings. (But I'm not at all an expert on RDF, and I may have
missed something in the microdata spec, so please let me know if I'm
wrong!)

-- 
Philip Taylor
exc...@gmail.com


Re: [whatwg] Annotating structured data that HTML has no semantics for

2009-05-14 Thread Shelley Powers

Dan Brickley wrote:

On 14/5/09 14:18, Shelley Powers wrote:

James Graham wrote:

jgra...@opera.com wrote:

Quoting Philip Taylor :


On Sun, May 10, 2009 at 11:32 AM, Ian Hickson  wrote:


One of the more elaborate use cases I collected from the e-mails
sent in
over the past few months was the following:

USE CASE: Annotate structured data that HTML has no semantics 
for, and

which nobody has annotated before, and may never again, for private
use or
use in a small self-contained community.

[...]

To address this use case and its scenarios, I've added to HTML5 a
simple
syntax (three new attributes) based on RDFa.


There's a quickly-hacked-together demo at
http://philip.html5.org/demos/microdata/demo.html (works in at least
Firefox and Opera), which attempts to show you the JSON serialisation
of the embedded data, which might help in examining the proposal.


I have a *totally unfinished* demo that does something rather similar
at [1]. It is highly likely to break and/or give incorrect results**.
If you use it for anything important you are insane :)


I have now added extremely preliminary RDF support with output as N3
and RDF/XML courtesy of rdflib. It is certain to be buggy.


So much concern about generating RDF, makes one wonder why we didn't
just implement RDFa...


Having HTML5-microdata -to- RDF parsers is pretty critical to having 
test cases that help us all understand where RDFa-Classic and HTML5 
diverge. I'm very happy to see this work being done and that there are 
multiple implementations.


As far as I can see, the main point of divergence is around URI 
abbreviation mechanisms. But also HTML5 might not have a notion 
equivalent to RDF/RDFa's bNodes construct. The sooner we have these 
parsers the sooner we'll know for sure.


Dan


Actually, I believe there are other differences, as others have pointed 
out.


http://www.jenitennison.com/blog/node/103

http://realtech.burningbird.net/semantic-web/semantic-web-issues-and-practices/holding-on-html5

Some of the differences have resulted in more modifications to the 
underlying HTML5 spec, which is curious, because Ian has stated in 
comments that support for RDF is only a side interest and not the main 
purpose behind the microdata section.


With the statement that support for RDF isn't a particular goal of 
microdata, Dan, I think you're being optimistic about the good this 
effort will generate for RDFa. But, more power to you.


Shelley


Re: [whatwg] Annotating structured data that HTML has no semantics for

2009-05-14 Thread Dan Brickley

On 14/5/09 14:18, Shelley Powers wrote:

James Graham wrote:

jgra...@opera.com wrote:

Quoting Philip Taylor :


On Sun, May 10, 2009 at 11:32 AM, Ian Hickson  wrote:


One of the more elaborate use cases I collected from the e-mails
sent in
over the past few months was the following:

USE CASE: Annotate structured data that HTML has no semantics for, and
which nobody has annotated before, and may never again, for private
use or
use in a small self-contained community.

[...]

To address this use case and its scenarios, I've added to HTML5 a
simple
syntax (three new attributes) based on RDFa.


There's a quickly-hacked-together demo at
http://philip.html5.org/demos/microdata/demo.html (works in at least
Firefox and Opera), which attempts to show you the JSON serialisation
of the embedded data, which might help in examining the proposal.


I have a *totally unfinished* demo that does something rather similar
at [1]. It is highly likely to break and/or give incorrect results**.
If you use it for anything important you are insane :)


I have now added extremely preliminary RDF support with output as N3
and RDF/XML courtesy of rdflib. It is certain to be buggy.


So much concern about generating RDF, makes one wonder why we didn't
just implement RDFa...


Having HTML5-microdata -to- RDF parsers is pretty critical to having 
test cases that help us all understand where RDFa-Classic and HTML5 
diverge. I'm very happy to see this work being done and that there are 
multiple implementations.


As far as I can see, the main point of divergence is around URI 
abbreviation mechanisms. But also HTML5 might not have a notion 
equivalent to RDF/RDFa's bNodes construct. The sooner we have these 
parsers the sooner we'll know for sure.


Dan



Re: [whatwg] Annotating structured data that HTML has no semantics for

2009-05-14 Thread Shelley Powers

James Graham wrote:

jgra...@opera.com wrote:

Quoting Philip Taylor :


On Sun, May 10, 2009 at 11:32 AM, Ian Hickson  wrote:


One of the more elaborate use cases I collected from the e-mails 
sent in

over the past few months was the following:

  USE CASE: Annotate structured data that HTML has no semantics 
for, and
  which nobody has annotated before, and may never again, for 
private use or

  use in a small self-contained community.

[...]

To address this use case and its scenarios, I've added to HTML5 a 
simple

syntax (three new attributes) based on RDFa.


There's a quickly-hacked-together demo at
http://philip.html5.org/demos/microdata/demo.html (works in at least
Firefox and Opera), which attempts to show you the JSON serialisation
of the embedded data, which might help in examining the proposal.


I have a *totally unfinished* demo that does something rather similar
at [1]. It is highly likely to break and/or give incorrect results**.
If you use it for anything important you are insane :)


I have now added extremely preliminary RDF support with output as N3 
and  RDF/XML courtesy of rdflib. It is certain to be buggy.


So much concern about generating RDF, makes one wonder why we didn't 
just implement RDFa...


Shelley


Re: [whatwg] Annotating structured data that HTML has no semantics for

2009-05-14 Thread James Graham

jgra...@opera.com wrote:

Quoting Philip Taylor :


On Sun, May 10, 2009 at 11:32 AM, Ian Hickson  wrote:


One of the more elaborate use cases I collected from the e-mails sent in
over the past few months was the following:

  USE CASE: Annotate structured data that HTML has no semantics for, and
  which nobody has annotated before, and may never again, for private 
use or

  use in a small self-contained community.

[...]

To address this use case and its scenarios, I've added to HTML5 a simple
syntax (three new attributes) based on RDFa.


There's a quickly-hacked-together demo at
http://philip.html5.org/demos/microdata/demo.html (works in at least
Firefox and Opera), which attempts to show you the JSON serialisation
of the embedded data, which might help in examining the proposal.


I have a *totally unfinished* demo that does something rather similar
at [1]. It is highly likely to break and/or give incorrect results**.
If you use it for anything important you are insane :)


I have now added extremely preliminary RDF support with output as N3 and 
 RDF/XML courtesy of rdflib. It is certain to be buggy.


Re: [whatwg] DOMTokenList is unordered but yet requires sorting

2009-05-14 Thread Kristof Zelechovski
If a token list represented an ordered set, it could not be sorted to get an
item because the host would have to preserve the original (document) order
of tokens.

Chris