[uf-discuss] Addressing bits of information

[Al Gilman]

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.

   http://lists.w3.org/Archives/Public/wai-xtech/2005Sep/0000

Al

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
>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 at microformats.org
>http://microformats.org/mailman/listinfo/microformats-discuss