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

Re: Display values for RDFa object URLs

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

Hi Niklas,

> 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..)

Just to be clear on this, the reason we're discussing rdfs:label is
because it is particularly innocuous. It's *not* dc:title, for
example. A rdfs:label is simply a human-readable version of a
resource--use it if you want, don't use it if you don't want to. But
either way, you would probably want something else to represent your
"explanatory texts".

> 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" .

I think this is confusing, but obviously if you have a use-case it can
be considered. I would like to see a different use case though, since
this one is at the core of what we are discussing. If you were arguing
that this use-case is so important that we need to change the
precedence of our attributes, then I would of course reply that it is
easier to do this by generating an dfs:label triple automatically.

> 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.

No disrespect, but over the years just about every permutation has
seemed 'intuitive' at one time or another--it really does depend on
which examples you are looking at. (For example, chaining was in the
first drafts, then it was dropped, and now it's back.)

> 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.)

Nor do I... :)

> 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" ] .

It's getting very complicated.

> (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?

There are too many special cases coming in for my liking. If you look
at chaining it's at least based on fairly easy to follow notions of
'nesting', but once you start getting attributes being used in
different ways depending on the presence of other attributes things
get difficult. (I recall years ago someone asking why shouldn't one or
other of @rel and @rev take priority if they are both present, but not
only are there good use cases for both, but it's a lot easier for
parsers and humans if they just process everything in a consistent



  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 13:16:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:23 UTC