[microformats-discuss] xFolk 0.4

Bud Gibson bud at thecommunityengine.com
Sun Jul 10 20:40:43 PDT 2005


Late here on the east cost.  Early in Israel I'm assuming.  The  
examples help, and I want to accommodate practice.

I think we agree on accommodating the <img> element.  I'm less  
adamant now about the taggelink name and its essential rightness.   
The key there is that we have a URL pointer, as you agree.

Do you really want to tag <span>'s?  Could you elaborate on that use  
case some more?  Here's what I currently understand:

1.  You want to tag the comment.  If the comment had a url, that  
would be easy.  Without a URL, harder, BUT the comment could easily  
have its own URL (give it an ID and then the URL is of the form  
http://somedomain.com/itemTagged#commentID).

2.  You want to identify tags by user for a single resource  (seems  
less likely).

Which of these is it?

Let's forestall a decision on taggedlink for now.  I see your  
argument, but I have to weigh it in light of changing the standard or  
adding an alias.  That complicates parsing, and others are just  
accepting taggedlink.  I still do like the idea of reinforcing we are  
talking about something linked to from the page.

Bud
On Jul 10, 2005, at 23:18, Eran wrote:

> Hi Bud,
>
> Thanks for the prompt response.
>
>
>> First off, xFolk has now graduated to RC1 and is on the wiki here:
>>
>> http://microformats.org/wiki/xfolk
>>
>>
>
> I've noticed that a coule of days ago and I must say I like the xFolk
> format. It's simple, to the point and does its job very well.
>
>
>> using just the word "tagged" or "xTagged"?  At the time, there was
>> some discussion in email about just what was being tagged.
>>
>
> That is exactly my question but I'm not looking to tag anything  
> that has
> no URL as you suggest next.
>
>
>> At the
>> end of the day, in a distributed web tagging system like xFolk or
>> reltag, you need  an address to point to because the data cannot be
>> assumed to be on your site.  The way to do this for items on the web
>> is to point at a URL.
>>
>>
>
> Pointing to a URL is a good way to identify a resource but I suggest
> that there's a difference between a link, the URL in the link's href
> attribute and the resource linked to. The link is an entity on its  
> own.
> The URL is an identifier for the resource and can be used as a  
> proxy for
> the resource. The resource is the page or image or snippet of text at
> the other end of the link. The object of the entry is the resource (or
> by proxy its URL) not the link to the resource so on a purely semantic
> level, taggedLink or taggedURL is misleading. Like I said this is a
> purely semantic point that can be easily be waved.
>
>
>>
>> Taggedresource seems less precise in light of this discussion
>> as does
>> tagged.  And I do think we need to be precise here because in xFolk,
>> we are talking about things with a web presence.
>>
>>
>
> As per my argument above, I believe that taggedResource is more  
> precise
> than taggedLink as it points out that the object being tagged is the
> pointed resource, not the link. Think of a case where I would make a
> reference to someone's bookmark, in this case the object would be the
> link (his link, not mine).
>
>
>>>
>>> As a follow-up, I'd like to bring up a question: would it be
>>> possible to
>>> use class="tagged" on different types of elements? Say, an IMG, or
>>> even
>>> just a SPAN? That would make it easier to tag rich-media objects in
>>> their "natural form", improving the microformats readability for
>>> people
>>> (when looking at a tagged image I expect to see an image
>>>
>> not a link to
>>
>>> one).
>>>
>>
>> I see no immediate reason not to take the <img> element into
>> account.  This is a very good point.
>>
>
> This part of the discussion actually brings up a more important  
> argument
> for changing taggedLink. For simplicity let's assume I'm using  
> xFolk for
> my photo tagging service. Following the microformat philosophy, I  
> would
> like to present the information in a way that's meaningful both to
> people and machines. For a machine, a URL is enough to identify a a
> resource so something like the following is enough:
>
> <span class="xfolkentry">
> <a class="taggedlink" href="http://example.com/image.png">my image</a>
> <a rel="tag" href="http://example.com/tag/foo">foo</a>
> </span>
>
> But to a human browing this page this makes little sense. The  
> following
> alternative representation might work better:
>
> <span class="xfolkentry">
> <img class="taggedresource" src="http://example.com/image.png" alt="my
> image">
> <a rel="tag" href="http://example.com/tag/foo">foo</a>
> </span>
>
> Using class="taggedlink" on an IMG element doesn't seem right. Of
> course, we can combine the two:
>
> <span class="xfolkentry">
> <a class="taggedlink" href="http://example.com/image.png">
>     <img src="http://example.com/image.png" alt="my image">
> </a>
> <a rel="tag" href="http://example.com/tag/foo">foo</a>
> </span>
>
> Which works very well for images but might not work so well for other
> media types (video, text snippets, etc.)
>
>
>> As for <span>, I see it
>> potentially having an identification issue as I discussed above.  As
>> a side note, in a discussion of semantics, <span> seems to be the
>> least semantic of elements.
>>
>>
>
> I only bring up span as a way to markup a arbitrary text snippet. I'm
> not sure why I want to tag arbitrary text but apparently, I do. Let's
> just say I want to tag someone's comments regarding some image. I  
> might
> want to be able to do something like:
>
> <span class="xfolkentry">
> <span class="note taggedresource">this is my note. There are many like
> it but this one is mine</span>
> <a rel="tag" href="http://example.com/tag/foo">foo</a>
> </span>
>
> I hope this helps to clarify my thoughts on the subject.
>
> Eran.
>
> PS.
> Mod: sorry for the double posts.
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>



More information about the microformats-discuss mailing list