Re: Display values for RDFa object URLs

Niklas,

one of my main problem with the proposal is the resulting asymmetry with
@rel. At the moment, both @property and @rel are general mechanisms to
generate triples, one for literals and one for URI resources (or blank
nodes) as objects, and the 'inherited' subject or (if present) @about as
subjects. This has the merit of being a clean model, easy to describe
and understand. Actually, @rev also falls into the same model nicely,
except that it reverses the roles.

With your model the behaviour of @property and @role would become
fundamentally different. I am sorry to say, but your use cases do not
convince me as sufficiently strong to justify such asymmetry:-(

Yes, I know, @instanceof is already an odd-man-out, because its subject
may be more complex to find out. And this *is* a bit messy but, well,
that was the only way we could properly do it. Note, however, that my
expectation v.a.v. @instanceof is quite different: the user of
@instanceof is a, in some way, RDF savy person who at least has a vague
idea on what RDF typing is all about. Put it another way, I expect most
of the RDFa users to use @rel and @property, mostly (and @about and the
others), so it is very important that those two properties behave in an
easily explainable way...

The problem is that neither you nor I have a measurable set of
experiences on what is more intuitive:-(

Cheers

Ivan

Niklas Lindström wrote:
> 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.
>>
>>

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf