Re: longdesc URLs and RDFa

Mark Birbeck, Wed, 18 Aug 2010 14:00:05 +0100:
> 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.

It is true that they already have semantics about the relationship 
between (in @longdesc's case) the subject (@src) and another resource. 
But, for instance, in @longdesc's case, the longdesc URL doesn't need 
to be another _page_, it could be a fragment on the same page. Whether 
it is another page or another fragment, can e.g be expressed via the 
predicate.

I don't think that @longdesc, when used inside RDFa, needs to show the 
exact same predicate/object relationship as a "pure" representation of 
the host language's built-in semantics represent.

For instance, when @cite points to a (re)source, then is that source an 
exact copy of what appears inside the <blockquote/>? That is: do you 
quote - in full - a fragment from the cited (re)source? Or does the 
@cite attribute point to the entire work in which the quoted fragment, 
somewhere, is found. This should be possible to express - and refine - 
via a predicate that the author selects.

It must be up to the author to not misuse @cite or @longdesc, from the 
point of view of the host language - same as for @src or @href.

E.g. sometimes newspapers publishes documents online in image form. Via 
@longdesc, one could link to a transcript. An RDFa predicate could 
declare the longdesc URL to represent a transcript. Thus, I don't see 
why the predicate must represent the host language's purist 
interpretation of what the longdesc relationship is.

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

W.r.t. @alt, then I don't only compare it with @content but also with 
<element>content</element>. The <element>content</element> of an 
element is more than some material that is waiting to be defined via 
RDFa. Thus, I cannot see that you have provided a sound justification 
for why it is illogical to treat @alt as @content.
 
> 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.

I don't agree that to treat @alt like @content/content is to ignore its 
semantics. I hold that it is the opposite way. And, above, I think I 
have justified why treating @longdesc and @cite as @resource/@href also 
isn't to step on the host language semantics.  

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

* Would an IMG with @longdesc be able to contain both a @longdesc and a 
@typeof attribute?

* Does the @typeof idea mean that the @longdesc URL *cannot* be 
interpreted as an object - simply by the presence of the @longdesc? 
Why, eventually, should one prevent that?  (I asked Toby the same 
question.) 

My current understanding is that to treat @longdesc as some kind of 
@typeof attribute would lock the RDFa interpretation of the @longdesc 
URL in a not useful way - see above.
-- 
leif halvard silli

Received on Wednesday, 18 August 2010 13:46:47 UTC