Re: [uf-discuss] Addressing bits of information
On May 25, 2006, at 5:25 PM, Scott Reynen wrote: On May 25, 2006, at 10:52 AM, Tantek Çelik wrote: What problem is this solving? What human readable content is this marking up? This is sounding off-topic for microformats. Am I missing something? I don't think it's about publishing microformats, but rather parsing microformats. That may be off-topic for this list, but it might be good to discuss on the microformats-dev list or somewhere, as a simple re-usable tool for pulling microformats out of documents would be useful for anyone building parsers. We have at least one of those already. See Assaf's ufparser [http:// trac.labnotes.org/cgi-bin/trac.cgi/wiki/Ruby/MicroformatParser]. -ryan___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Addressing bits of information
Eugene has posted an interesting issue that might benefit from some mF insight... how do we create URIs for partial bits of data like a word or hcard in the middle of a paragraph? http://www.eekim.com/blog/tech/hyperscope/hyperscopeuri.html Chris ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Addressing bits of information
At 01:04 -0700 25.05.2006, Chris Messina wrote: Eugene has posted an interesting issue that might benefit from some mF insight... how do we create URIs for partial bits of data like a word or hcard in the middle of a paragraph? Referencing particular document fragments within an XML document (which an XHTML page necessarily is) is supposedly the province of XPointer: http://www.w3.org/XML/Linking It might be worth looking at that rather than reinventing that particular wheel, although the XPointer syntax (which draws on XPath) might be a little scary for most authors. There's also the problem that nothing in wide use today actually supports XPointer, although perhaps Javascript could come to the rescue here, at least for simple cases? Angus ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Addressing bits of information
They're called fragment identifiers and they're common practice already in (X)HTML: http://www.w3.org/TR/REC-html40/intro/intro.html#h-2.1.2 -ryan On May 25, 2006, at 9:04 AM, Chris Messina wrote: Eugene has posted an interesting issue that might benefit from some mF insight... how do we create URIs for partial bits of data like a word or hcard in the middle of a paragraph? http://www.eekim.com/blog/tech/hyperscope/hyperscopeuri.html Chris ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Addressing bits of information
On 5/25/06, Ryan King [EMAIL PROTECTED] wrote: They're called fragment identifiers and they're common practice already in (X)HTML: It's often convenient to be able to point to bits of a document that haven't been annotated with fragment identifiers. -- Christopher St. John http://artofsystems.blogspot.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Addressing bits of information
On May 25, 2006, at 3:04 AM, Chris Messina wrote: how do we create URIs for partial bits of data like a word or hcard in the middle of a paragraph? http://www.eekim.com/blog/tech/hyperscope/hyperscopeuri.html I'm not sure that's really the question being asked by Eugene. It sounds like the addressing of HyperScope goes beyond specific fragments: It can do path expressions, similar in spirit to XPath, which allows you to reference some subset of nodes in a document. This sounds to me like, e.g., a URI that references all the TEL elements in a document, and only those elements, so the client can read the URI, load the document, and strip it down to the specified nodes. So the question being asked is whether this would be better as http://domain.org/?hyperscope=class:tel or http://domain.org/ #hyperscope:class-tel or something else. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Addressing bits of information
So, this is like W3 Selectors for URLs? :DG On 5/25/06, Scott Reynen [EMAIL PROTECTED] wrote: On May 25, 2006, at 3:04 AM, Chris Messina wrote: how do we create URIs for partial bits of data like a word or hcard in the middle of a paragraph? http://www.eekim.com/blog/tech/hyperscope/hyperscopeuri.html I'm not sure that's really the question being asked by Eugene. It sounds like the addressing of HyperScope goes beyond specific fragments: It can do path expressions, similar in spirit to XPath, which allows you to reference some subset of nodes in a document. This sounds to me like, e.g., a URI that references all the TEL elements in a document, and only those elements, so the client can read the URI, load the document, and strip it down to the specified nodes. So the question being asked is whether this would be better as http://domain.org/?hyperscope=class:tel or http://domain.org/ #hyperscope:class-tel or something else. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Addressing bits of information
Ooo.. that would be cool... I might sound dumb by saying this, but would that be like a RESTian way of accessing data in a microformatted page? Chris On 5/25/06, Dimitri Glazkov [EMAIL PROTECTED] wrote: So, this is like W3 Selectors for URLs? :DG On 5/25/06, Scott Reynen [EMAIL PROTECTED] wrote: On May 25, 2006, at 3:04 AM, Chris Messina wrote: how do we create URIs for partial bits of data like a word or hcard in the middle of a paragraph? http://www.eekim.com/blog/tech/hyperscope/hyperscopeuri.html I'm not sure that's really the question being asked by Eugene. It sounds like the addressing of HyperScope goes beyond specific fragments: It can do path expressions, similar in spirit to XPath, which allows you to reference some subset of nodes in a document. This sounds to me like, e.g., a URI that references all the TEL elements in a document, and only those elements, so the client can read the URI, load the document, and strip it down to the specified nodes. So the question being asked is whether this would be better as http://domain.org/?hyperscope=class:tel or http://domain.org/ #hyperscope:class-tel or something else. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Addressing bits of information
On May 25, 2006, at 10:52 AM, Tantek Çelik wrote: What problem is this solving? What human readable content is this marking up? This is sounding off-topic for microformats. Am I missing something? I don't think it's about publishing microformats, but rather parsing microformats. That may be off-topic for this list, but it might be good to discuss on the microformats-dev list or somewhere, as a simple re-usable tool for pulling microformats out of documents would be useful for anyone building parsers. And more parsers makes the benefits of microformats more obvious to publishers. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Addressing bits of information
On 5/25/06 9:25 AM, Scott Reynen [EMAIL PROTECTED] wrote: On May 25, 2006, at 10:52 AM, Tantek Çelik wrote: What problem is this solving? What human readable content is this marking up? This is sounding off-topic for microformats. Am I missing something? I don't think it's about publishing microformats, but rather parsing microformats. That may be off-topic for this list, but it might be good to discuss on the microformats-dev list or somewhere It's sort-of offtopic - in other words, such discussions really should be on microformats-dev as you say, by folks who are actually working on parsing microformats. If you are working on parsing microformats, please say so here and sign up on the microformats-dev list! http://microformats.org/discuss as a simple re-usable tool for pulling microformats out of documents would be useful for anyone building parsers. And more parsers makes the benefits of microformats more obvious to publishers. Yes, that definitely makes sense. But discussions of extending URL/URI semantics for addressing bits of information? I'm not sure that actually has much bearing on parsing microformats. But like I said, perhaps I am missing something. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Addressing bits of information
Tantek Çelik wrote: But discussions of extending URL/URI semantics for addressing bits of information? I'm not sure that actually has much bearing on parsing microformats. But like I said, perhaps I am missing something. I don't know if my interpretation brings this on topic or just clarifies (or confuses…) but the problem as I understand it, is exemplified like so: I have a page listing 12 events using hCalendar. None of the hevent nodes have an ID and therefore cannot be referenced through fragments. However, I want to pass one of these events to a web service (say a Technorati pipe to generate an ICS file for the specific event). There's no way to do that. Same thing with a page containing multiple hCards. However, I honestly think that this problem is best solved by emphasising the need/benefit of putting IDs on vcard/vevent nodes, rather than inventing/adopting something more complex. Personally, I wouldn't think it unreasonable to have 'microformats must have an ID' as part of each spec. I don't think we should overcomplicate the issue with talk of technology like XPointer or Selectors which are unimplemented in the areas needed to 'fix' this. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Addressing bits of information
On 5/25/06, Ben Ward [EMAIL PROTECTED] wrote: Personally, I wouldn't think it unreasonable to have 'microformats must have an ID' as part of each spec. Note that requiring id's complicates authoring (first, you gotta come up with one, and unless you pick very wisely, you risk conflicts when you cut/paste/aggregate) Id's are great for bits of a document with logical, scoped names (like chapters, or footnotes), and for things that are truly unique in all the world and deserve their own guid. -- Christopher St. John http://artofsystems.blogspot.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Addressing bits of information
On May 25, 2006, at 1:00 PM, Ben Ward wrote: Tantek Çelik wrote: But discussions of extending URL/URI semantics for addressing bits of information? I'm not sure that actually has much bearing on parsing microformats. But like I said, perhaps I am missing something. I don't know if my interpretation brings this on topic or just clarifies (or confuses…) but the problem as I understand it, is exemplified like so: I have a page listing 12 events using hCalendar. None of the hevent nodes have an ID and therefore cannot be referenced through fragments. However, I want to pass one of these events to a web service (say a Technorati pipe to generate an ICS file for the specific event). There's no way to do that. Same thing with a page containing multiple hCards. However, I honestly think that this problem is best solved by emphasising the need/benefit of putting IDs on vcard/vevent nodes, rather than inventing/adopting something more complex. Personally, I wouldn't think it unreasonable to have 'microformats must have an ID' as part of each spec. I don't think we should overcomplicate the issue with talk of technology like XPointer or Selectors which are unimplemented in the areas needed to 'fix' this. Ben Thanks for the clear post Ben. This is very much the same issue that I've mentioned a few times WRT consuming hatom documents the added 'bonus' if you will with hatom is that you're typical usage will be to return to that document (or document fragment) repeatedly over time so its more important to handle some error conditions or other document changes over time. I do think that 'root element must have id' goes a long way to solving the problem on the hatom side, but I don't know if that alone gets us all the way there. And that says nothing about the questions of how a typical user might be able to identify the specific hcard/hevent/hatom/xoxo fragment to pass to another application if there was an ID requirement in place. In the above scenario you'd still have to have a way of learning that #event-002 is *the* event you want to spread around -- other then knowing because you're the author or you viewed source. -- [ Chris Casciano ] [ [EMAIL PROTECTED] ] [ http://placenamehere.com ] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Addressing bits of information
On 5/25/06 10:46 AM, Scott Reynen [EMAIL PROTECTED] wrote: On May 25, 2006, at 12:20 PM, Tantek Çelik wrote: There is already an easy solution that works for publishers (ID). Inventing a more complex solution will not result in more adoption. My understanding of HyperScope would accomplish a bit more than ID attributes could. IMHO, it fails the good enough comparison with ID. ID is good enough (or certainly, has a lot more potential than is currently being used), thus it is not really worth spending time on a more complex system (at least for now). While a standard means of combining something like XPATH with URIs would be a more complicated addressing scheme, it would allow more complicated addressing (e.g. I want every vcard on a page not part of an address tag, or the first paragraph within any entry-content), and it would require no additional action by publishers. And this aspect is I believe why it is off-topic for this list. It has nothing to do with helping content publishers more semantically markup their content. I think it would probably be closer to XSLT than ID. It wouldn't directly affect adoption at all, but as someone who likes to play with microformat parsers when I have time, I'd have more time for such play if I could reliably delegate the extraction of the content I want to another tool with a single, if complex, URI. From what I can tell, and the example you gave of every vcard on a page not part of an address tag, this is really about developing yet another query language for structured/semantic content. Thus, in that vein, I'd say look first not only at XSLT/XPath, but also SQL, XQuery, and SPARQL. This is a space with LOTS of existing work and solutions, and once again, I am not convinced that there is a need for yet another one. Or rather, there is a much larger burden of proof/justification than I have seen to date. If you really want to leave the parsing/extraction to other tools, and only want to access the results via queries, then look into existing solutions that load/parse microformats into RDBMS/XML/RDF etc. and then allow querying via SQL/XPath/SPARQL etc. Maybe that's a pipe dream, but it's one that would result in more microformat-consuming applications, Maybe. That's one hypothesis. I for one believe that the majority of consumption is going to happen directly. Fewer pieces, fewer moving parts, more reliable etc. That is, people are loading/parsing microformats directly into whatever applications they are building, via libraries in common frameworks (see the microformats wiki for links to such libraries for various microformats). The easiest way to explain to a publisher why they want to be using microformats is to point to all the tools microformats allow them to interact with, Right, and as such it immediately makes sense for all publishers to adopt hCard and hCalendar and offer Add to Address Book and Add to Calendar links. so I don't think parsers and publishers can really be separated in any discussion of adoption. Encouraging either one encourages the other. The majority of folks don't care nor bother with details of parsing - that's why that topic is preferred for the dev list. In addition, discussion of new abstract addressing methods, which are unnecessary for parsers, can certainly be separated from any discussion of publishing or adoption, and frankly for that matter, this list. All of us need to be active and vigilant in filtering out hypothetical solutions to imagined problems so that we can focus on practical solutions to real world problems while (re)using existing techniques and technology building blocks as much as possible. That's what makes this community different from other problem solving communities. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
