Re: longdesc URLs and RDFa

Hi Leif,

I think @cite and @longdesc are more than just a resource waiting for
a predicate to be defined. They already have semantics about a
relationship between the current document and another, it's simply
that those semantics haven't been defined in RDF terms.

Similarly, @alt is more than just a plain literal waiting for a
predicate to be defined. It has the semantics of being a label for a
resource, but once again there is no precise definition for it, in RDF
terms.

So, whilst one /could/ ignore the semantics of these attributes, and
treat them as the same as @resource and @content, that would be to
ignore the semantics that HTML already gives to these attributes.

It would be far better to say that these attributes define a
predicate/object couplet in just the same way that @typeof does. But
what I'm also saying is that this is not something that should be done
in the RDFa specification, but in the HTML/XHTML ones.

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)



On Wed, Aug 18, 2010 at 1:30 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> Mark Birbeck, Wed, 18 Aug 2010 12:39:32 +0100:
>> Hi Ivan/Leif,
>>
>> On Wed, Aug 18, 2010 at 11:44 AM, Ivan Herman <ivan@w3.org> wrote:
>>> Leif,
>>>
>>> thanks. I think I indeed misunderstood you. If I concentrate on the
>>> image related
>>> attributes, what you seem to say is that:
>>>
>>> - the value of @longdesc should be treated as if it was a @resource
>>> - the value of @alt should be treated as if it was @content
>>>
>>> and that is all. Correct?
>>>
>>> Sorry for the misunderstanding
>>>
>>> Ivan
>>
>> This doesn't work, I'm afraid, because @longdesc, @cite and @alt are
>> *very* different to @resource and @content.
>>
>> @resource and @content are generic containers for objects (and
>> subjects...sometimes) and for that reason are general-purpose. We
>> added support for @src for the same reason -- that it's generic.
>
> You don't mention @href. (My understanding is that @href and @resource
> are synonyms.)
>
> "Generic" can be used in at least two senses: 1) as "the common way",
> 2) as "the general purpose way". I believe you use it in the second
> way. (?) And I believe @data is generic in that same sense.
>
> As for @cite and @longdesc, they are not generic in the second sense -
> I admit that. But it is possible to map them to the same generics. How
> would that be to step on the semantics of the host language?
>
> Like I said: Even by supporting @src, you step on the semantics of the
> host language - it enables embed@src (forbidden syntax in today's HTML
> recommendations).
>
>> @alt, @cite and @longdesc on the other hand are predicate/object
>> couplets, and for that reason they require a decision to be made about
>> which predicate to map to. If we were to do that mapping then it would
>> take us away from providing a generic *framework* for semantics, to
>> actually defining the semantics themselves.
>
> Why do @cite and @longdesc need any more such decision than @href? By
> treating them like @href, they would not generate triples unless the
> authors themselves adds the predicate.
>
>> That's why at the very beginning of this discussion I said that we
>> should look at how we allow host languages to define their own
>> 'mappings' from attributes and elements to predicates. If we provided
>> that capability it would then allow people to define an interpretation
>> not only for @alt, @cite and @longdesc, but also for <title> and a
>> bunch of other things, too.
>
> I think my idea, from the start, was - as you say - that @cite and
> @longdesc already indicate a predicate/object couplet. Now my idea has
> changed a little. I think even whether it is true that it defines a
> such couplet, should be up to the language.
>
> But what is cannot be disputed, is that @cite/@longdesc are links -
> like @href is a link. And, by treating them like @resource/@href, RDFa
> would allow people to define an interpretation of those attributes,
> without defining a host vocabulary mapping first. I don't think this
> steps on the semantics of the host language.
>
> This doesn't preclude offering a way for the host language to define
> @cite/@longdesc as couplets.
>
>> (<title> is a good example of the problem we face once we move into
>> semantics; should <title> map to 'dc:title'? Lots of people think it
>> should, and we could spend weeks just discussing that. My response
>> would be that it's none of our business -- we are in the business of
>> providing a *framework* for semantics, and we let other people define
>> the semantics themselves.)
>>
>> The only attribute we have in the current spec that is comparable to
>> @cite et.al, is @typeof, which represents *both* a predicate of
>> 'rdf:type' *and* a resource. However, that particular exception is
>> driven by the needs of RDF and not HTML.
>>
>> So in summary, I don't doubt that it's possible to come up with
>> suitable mappings for these attributes, but I don't believe it's our
>> place to do so. A fundamental tenet of RDFa from the start was to
>> focus on a framework for semantics rather than the semantics
>> themselves, and that is what allowed us to avoid the 'Microformats
>> trap' (i.e., leave the definition of any actual semantics to the
>> specialists).
>
> Would you say that RDFa risk landing in a trap if it simply treats
> @cite and @longdesc as @resource/@href?
> --
> leif halvard silli
>

Received on Wednesday, 18 August 2010 13:01:01 UTC