W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > August 2007

Re: Display values for RDFa object URLs

From: Niklas Lindström <lindstream@gmail.com>
Date: Fri, 10 Aug 2007 14:26:52 +0200
Message-ID: <cf8107640708100526g2ea52397g3a883e8921b579f2@mail.gmail.com>
To: "Mark Birbeck" <mark.birbeck@formsplayer.com>
Cc: "Ivan Herman" <ivan@w3.org>, "Manu Sporny" <msporny@digitalbazaar.com>, "RDFa mailing list" <public-rdf-in-xhtml-tf@w3.org>

Hello!

I agree with Ivan, there is a definite risk of generating non-intended
triples if such a rule was applied. (As I hope to use RDFa in the
markup of very formal information, I wouldn't want references (links)
in that to have their explanatory texts become their labels all the
time. If they did, I'd have no easy way to remove them from the graph
either..)

This all begs the question: how do you regard the thoughts about
@property and chaining as I mentioned at the end (last block) of:

   <http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Aug/0069.html>

? That is, is it far-fetched to consider having the subject used for a
@property also depend on the new chaining rules? While it, as I
mention in the mail referenced, *could* make current examples invalid,
I *believe* those are edge cases. I think of e.g.:

    <span about="#me" rel="foaf:depiction" resource="me_at_work.jpg"
property="foaf:name">Niklas</span>

which today yields:

    <#me> foaf:depiction <me_at_work.jpg> .
    <#me> foaf:name "Niklas" .

In my (contrived?) opinion, I think this is better expressed as two
separate things, like:

    <div about="#me">
        <span rel="foaf:depiction" resource="me_at_work.jpg" />
        <span property="foaf:name">Niklas</span>
    </div>

To me, having both @rel and @property in the same element (with the
intent of having the same subject for them) feels a little "cramped"
-- wherefore I guess it may be rare in practise. I think that it would
be more intuitive to change the rules so that the combination, by
effect of the chaining rules, will work so that this:

    <a about="#me" rel="foaf:depiction" href="me_at_work.jpg"
property="rdfs:label">Me at work</a>

yields:

    <#me> foaf:depiction <me_at_work.jpg> .
    <me_at_work.jpg> rdfs:label "Me at work" .

Meaning that @property applies to "current RDF identity". As said,
this is how Manu tried to do it, which hints at it being the more
intuitive way. It is (AFAIK) symmetric with how @instanceof works in
that the subject is the current one unless any @rel/@rev changes it by
chaining.

And one benefit is surely that rdfs:label can be worked in again with
less effort, still be explicit (as I along with Ivan strongly believe
it should be), interchangeable with other properties where appropriate
(like foaf:name) and possible to override with @content as usual.

(This also suggests that we *could choose to* interpret @title as a
direct shorthand for e.g. property="rdfs:label" content="{@title}".
Note that I do not suggest this myself at the moment.)

Another effect is the possibility of creating "tiny bnodes with one
literal statement", such as:

    <ul about="#a_group">
        <li rel="foaf:member" property="foaf:givenname">Ivan</li>
        <li rel="foaf:member" property="foaf:givenname">Mark</li>
    </ul>

yielding:

 <#a_group>
    foaf:member [ foaf:name "Ivan" ];
    foaf:member [ foaf:name "Mark" ] .

(Here I intentionally sneak in my assumption that html lists won't be
implicitly interpreted as collections, they have to be typed. This is
how pyRdfa works today.)

Thoughts?

Best regards,
Niklas



On 8/10/07, Mark Birbeck <mark.birbeck@formsplayer.com> wrote:
>
> 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:27:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:15:09 GMT