Re: Display values for RDFa object URLs

Hi Manu,

We seem to be forgetting what we already have from HTML.

> +1: We don't want to guess at what the publishers intent is...
>
> Here's a real-world problem that we've hit with hAudio uF:
>
>    <div about="#song" instanceof="hmedia:Audio">
>     <a rel="hmedia:sample"
>        href="http://www.bitmunk.com/sample/6011101">
>           <img src="images/sample.png" alt="Image of Sample" />
>           A Sample
>     </a>
>    </div>
>
> Do you use the text "Image of Sample", or "Sample" in this case?

Forget for a moment whether we want rdfs:label...there is little
ambiguity here. In HTML, the @alt applies to the image--why would it
even be considered as an alternative label for the link?

However, I can see that some people might suggest that "Image for
Sample" is a _replacement_ for the image, and therefore might suggest
that instead of this:

  "A Sample"

the following could be generated:

  "Image of SampleA Sample"

In other words, I can see that people might get themselves into a bit
of an Alice in Wonderland world of recursion, treating "Image of a
Sample" as a textual representation of the image, and therefore
'replacing' the image with that value when working out the contents of
the <a>.

But in RDFa, the rules are pretty clear, and it would be difficult to
make a case for that.


> How
> deeply to you peek into sub-elements?

We don't really have that notion in our parsing. RDFa is more of a
'have I got enough to make a triple yet?' approach. We only take the
content of an element, either as XML or as a string. (I wrote an
RDF/XML parser years ago, and it's almost exactly the same approach.)


> The Microformats community is
> still deliberating on this. Most have identified this as an parser
> implementation detail that the parser authors need to deal with. It
> looks like the community is not going to take a stance on it :).

:)


> My take is that we need to publish a "best practices" to guide for the
> hAudio parser writers and let them know what a reasonable display value
> fallback should be:

Don't forget we're dealing with triples--so what does 'display value
fallback' mean? Once you have your triples you can do what you want
with them, and you might choose to use an associated dc:title value as
your 'display value', or something derived from some other triple
store altogether. (Not to mention that my browser might choose an
English version of the labels whilst Ivan's chooses Hungarian.)


> 1. If @title is given for the A element, use that.
> 2. Use the text that would be shown for the link text if there are no
>    other markup elements in the link text (such as an image).
> 3. If there is an image with @alt specified, use the value that would be
>    displayed in a text-browser or screen reader.
>
> and so on...
>
> However, the RDFa folks don't need to take this approach as there seems
> to be a better option (using rdfs:label explicitly).

You can say that for people who are _both_ publishers and consumers of
their own data, but it's not better for those who are trying to
consume other people's data since there are almost certainly going to
be no labels for links.


> ----------------------------------------------------------------------
>
> +1: for explicitly stating what you want an rdfs:label to be.
>
>    <div about="#song" instanceof="hmedia:Audio">
>     <a rel="hmedia:sample"
>        href="http://www.bitmunk.com/sample/6011101">
>           <img property="rdfs:label" src="images/sample.png"
>                alt="Image of Sample" />
>           A Sample
>     </a>
>    </div>
>
> In the above example, the publisher has made it explicit that they want
> "Image of Sample" to be the rdfs:label for the @href.

Like I said, there is no notion in RDFS of *the* label, only one of
many. If you want something more concrete then you should really use
some other predicate, and then of course you would express that
property explicitly. For example, if I created a link to your FOAF
document, and put your name in the link, I'd almost certainly set the
property to be foaf:name, and not rdfs:label. The former (foaf:name)
specifies a property of you, whilst the latter (rdfs:label) says
*only* that we have "a human-readable representation" of a resource.
(Which we might or might not want to make use of.)

I could turn this whole thing round, by the way, and say that if I create this:

  <a rel="p" href="o">literal</a>

have I *not* got "a human-readable representation of a resource"? In
other words, put aside the question of control--which I think is a red
herring--are we saying that the information that the author has
provide in the <a> is *not* in some way a usable representation of the
resource being linked to, and that this representation is *not* human
readable?


> I don't think it
> is too much to ask publishers to specify an rdfs:label if they have a
> preference. If they don't have a preference, then it would be up to the
> application to pick something. I don't think this is a decision that the
> RDFa folks should be making for the application authors. In other words:
> we should enable people to specify display values, but we shouldn't try
> to guess what those values should be. Keep RDFa lean and put the power
> to explicitly state display values in the publishers hands. :)

It is leaner to not have to express the @property, surely?


> ---------------------------------------------------------------------
>
> In general, metadata markup such as this should be explicit, not
> implicit.

With respect, I'd refer you to my earlier comments about the fact that
part of what RDFa is all about is formalising the already existing
metadata in HTML. Unless you want to make it all explicit (i.e., use
special purpose languages such as RDF/XML or N3), then we are going to
have to deal with questions of interpretation.


> The publisher should be able to explicitly state what the
> value should be... if they don't have a preference, that decision should
> be left up to the application author. This approach means that:
>
> - We don't have to change/complicate the parsers.
> - The publisher has full control on the RDFa output.
> - This "rdfs:label concept" should probably be placed in a "best
>   practices" document.
>
> Just my $0.02...
>
> -- manu
>
> [1]http://microformats.org/wiki/audio-info-issues#Problem:_Display_properties_of_rel-patterns
> [2]http://microformats.org/wiki/audio-info-issues#Problem:_Peeking_into_child_elements
> [3]http://microformats.org/wiki/audio-info-issues#Historical:_Graphic_buttons_in_rel-patterns

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Friday, 10 August 2007 15:10:01 UTC