Re: Display values for RDFa object URLs

Hi Ivan,

> I understand the intention, I see the solution, but I am not convinced:-(.

:)


> I think we should keep such 'implicit' rules of triple generation to the
> minimum. We try to second guess the author's intentions here and I am
> not sure that is justified.

We don't actually try to 'second guess' intentions at all; we try to
provide an *interpretation* of the mark-up in triple form, that could
be said to be legitimate based on the HTML spec. If I say @rel="x"
then the HTML spec says that I'm establishing a relationship between
one document and another, so we can legitimately use the contents of
@rel as a predicate. Similary if I say <a href="x">y</a> then I have
unavoidably provided text to label a link--there is no second guessing
of the author's intentions going on there at all, since in fact the
browser is obliged to use that label on the link.


> There are a number of Web pages, for
> example, that use the (absolutely horrible!) 'click here' or 'see here',
> or similar content to <a>. Yes, it is a very bad design, but it is
> there. Ie, we will get a bunch of meaningless rdfs:label-s...

Now it's my turn to be not convinced...so what? :)


> As you say, the construction:
>
> <div about="#song" instanceof="hmedia:Audio">
>  <a rel="hmedia:sample" href="http://www.bitmunk.com/sample/6011101">
>        <span property="rdfs:label">A Sample</span>
>  </a>
> </div>
>
> works, it makes it explicit what the user wants, and also gives him/her
> to possibility to fine tune what should be a label and what shouldn't.

But like I say, they have already said what should be a label--that's
the contents of the <a>. I'd be interested to hear other points of
view, but I don't see using the text as an rdfs:label as very
controversial. The reason it hasn't been in the spec for so long--and
I've had this pending action item to 'work it back in'--is because
it's been difficult to come up with a simply rule that justifies
attaching the label to the @href. Now we're dealing with chaining
again, it seems more logical.


> It also opens the flood gates to a bunch of other questions. Do you want
> to introduce the same mechanism everywhere where one would use @href
> (after all, we opened this particular flood gate by allowing @href
> everywhere!)? What happens if I use @resource on <a> but no @href? What
> happens if there is additional markup within <a>? All set of additional
> issues that (1) has to be answered (2) has to be specified in the
> syntax, thereby making it more complicated (3) has to be properly
> explained in a primer document (4) has to be documented with test cases,
> etc, etc. I just do not see that avoiding one additional <span>
> justifies these costs...

I don't see it as being so complicated. In my view this kind of thing
makes things much simpler, because authors add less code, not more.

In my version, the author simply creates a link using ordinary
mark-up, in the way they are used to as an HTML author:

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

Our RDFa rules then say that this link--which HTML defines as being a
combination of a target document with some text to describe the
navigation to it--will generate two triples (which reflects that
combination). The first triple describes the relationship between the
current document and the target, and the second describes the label
used to refer to that target document.

In the 'longhand' version though, the author has to add more mark-up
to indicate that they want a label for the link, which is far more
confusing, since most authors will rightly say, but haven't I already
specified a label? This won't get done, since there is no particular
reason that authors would think they need to do this, and then we have
nothing in our parsed output that can be used to label the links.

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 12:05:53 UTC