[uf-discuss] Addressing bits of information
Alfred.S.Gilman at IEEE.org
Thu May 25 13:45:12 PDT 2006
Pardon what may sound like a late hit, but please let me point out
that the most
low-level and hence most useful of these random-access URIs (leading to
an un-ID-ed point in the cited page) is now available in running code
to all of us.
At 11:13 AM -0700 5/25/06, Tantek Çelik wrote:
>On 5/25/06 10:46 AM, "Scott Reynen" <scott at randomchaos.com> 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
>> 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
>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"
>> 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.
>microformats-discuss mailing list
>microformats-discuss at microformats.org
More information about the microformats-discuss