Re: [whatwg] DOMTokenList is unordered but yet requires sorting
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
Re: [whatwg] Annotating structured data that HTML has no semantics for
jgra...@opera.com wrote: Quoting Philip Taylor excors+wha...@gmail.com: On Sun, May 10, 2009 at 11:32 AM, Ian Hickson i...@hixie.ch 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] Annotating structured data that HTML has no semantics for
James Graham wrote: jgra...@opera.com wrote: Quoting Philip Taylor excors+wha...@gmail.com: On Sun, May 10, 2009 at 11:32 AM, Ian Hickson i...@hixie.ch 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
On 14/5/09 14:18, Shelley Powers wrote: James Graham wrote: jgra...@opera.com wrote: Quoting Philip Taylor excors+wha...@gmail.com: On Sun, May 10, 2009 at 11:32 AM, Ian Hickson i...@hixie.ch 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
Dan Brickley wrote: On 14/5/09 14:18, Shelley Powers wrote: James Graham wrote: jgra...@opera.com wrote: Quoting Philip Taylor excors+wha...@gmail.com: On Sun, May 10, 2009 at 11:32 AM, Ian Hickson i...@hixie.ch 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
On Thu, May 14, 2009 at 1:25 PM, Dan Brickley dan...@danbri.org 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: urn:subject urn:predicate urn:object . urn:subject urn:predicate object . urn:subject urn:predicate object@lang . urn:subject urn:predicate _:X . _:X urn:predicate urn:object . _:X urn:predicate object . _:X urn:predicate object@lang . _:X urn:predicate _:Y . These cases can be trivially mapped into HTML5 microdata as: div item link itemprop=about href=urn:subject link itemprop=urn:predicate href=urn:object /div div item link itemprop=about href=urn:subject meta itemprop=urn:predicate content=object /div div item link itemprop=about href=urn:subject meta itemprop=urn:predicate content=object lang=lang /div div item link itemprop=about href=urn:subject meta itemprop=urn:predicate item id=X /div link subject=X itemprop=urn:predicate href=urn:object meta subject=X itemprop=urn:predicate content=object meta subject=X itemprop=urn:predicate content=object lang=lang meta subject=X itemprop=urn:predicate item id=Y (There's the caveat about link and meta being moved into head in some browsers; you can replace them with a and span 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: http://www.w3.org/1999/xhtml/vocab#item urn:subject . http://www.w3.org/1999/xhtml/vocab#item urn:subject . http://www.w3.org/1999/xhtml/vocab#item urn:subject . http://www.w3.org/1999/xhtml/vocab#item urn:subject . urn:subject urn:predicate urn:object . urn:subject urn:predicate object . urn:subject urn:predicate object@lang . urn:subject urn:predicate _:n0 . _:n0 urn:predicate urn:object . _:n0 urn:predicate object . _:n0 urn:predicate object@lang . _:n0 urn:predicate _: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
[whatwg] A Selector-based metadata proposal (was: Annotating structured data that HTML has no semantics for)
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
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
Re: [whatwg] video/audio feedback
On Tue, May 12, 2009 at 9:29 PM, David Singer sin...@apple.com wrote: At 12:09 +1000 13/05/09, Silvia Pfeiffer wrote: On Wed, May 13, 2009 at 5:01 AM, Jonas Sicking jo...@sicking.cc wrote: On Sun, May 10, 2009 at 6:56 PM, David Singer sin...@apple.com 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
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] Annotating structured data that HTML has no semantics for
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
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
On Thu, May 14, 2009 at 3:54 PM, Philip Taylor excors+wha...@gmail.com 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 m...@apple.com 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] DOMTokenList is unordered but yet requires sorting
On Thu, May 14, 2009 at 00:30, Kristof Zelechovski giecr...@stegny.2a.pl 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
[whatwg] [Fwd: Re: Helping people seaching for content filtered by license]
sorry, forgot to cc the list Weitergeleitete Nachricht Von: Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net An: Ian Hickson i...@hixie.ch 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: figure video src=http://example.com/videodata/sJf-ulirNRk; controls a href=http://video.example.com/watch?v=sJf-ulirNRk;Watch/a /video legend Pillar post surgery, starting to heal. smallcopy; copyright 2008 Pillar. All Rights Reserved./small /legend /figure 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: figure img src=http://nearimpossible.com/DSCF0070-1-tm.jpg; alt= legend Picture by Bob. smalla href=http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode;Creative Commons Attribution-Noncommercial-Share Alike 2.5 Generic License/a/small /legend /figure Can I infer from this that an a in a small inside a legend 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
Re: [whatwg] Annotating structured data that HTML has no semantics for
On Thu, May 14, 2009 at 5:00 PM, Jonas Sicking jo...@sicking.cc 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 time element with a standardized microformat, such as: Christmas is going down on span item=w3c.time itemvalue=12-25-2009The 25th day of Decemberspan! (Though I'd probably avoid prefixes for 'standardized' item names). Hmm.. I guess the syntax would be span item itemprop=w3c.time propvalue=12-25-2009 Not very nice I admit. / Jonas
Re: [whatwg] Annotating structured data that HTML has no semantics for
On Thu, May 14, 2009 at 2:54 PM, Philip Taylor excors+wha...@gmail.com wrote: [...] urn:subject urn:predicate _:X . [...] div item link itemprop=about href=urn:subject meta itemprop=urn:predicate item id=X /div [...] 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 http://www.w3.org/1999/xhtml/vocab#item, 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 urn:predicate _: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
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
