[uf-discuss] Addressing bits of information

[Tantek Ç elik]

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