Re: [ALL] RDF/A Primer for review - Response to Pat Hayes's Comments

Pat,

Thanks for your comments on the RDF/A Primer. Please find, below, the  
answers we came to during our latest telecon:

> Overall, very nice.

Thanks!

> Few quibbles/niggles:
>
> 1. Why use "content" for an explicit object/value? We already have
> too many words for this, and that particular word is kind of
> subject/object neutral so IMO could lead to confusion, eg folk come
> to see this as a text/URI alternator, and then use it to indicate a
> subject, rather than "about". I'd suggest an unmistakeable neologism
> like 'pvalue' or 'propvalue' (I know its ugly, thats the point :-)

"content" is, in fact, the attribute that HTML has used since HTML4  
for this very purpose of attaching metadata. An important goal of RDF/ 
A is to provide a natural transition for HTML authors, thus the reuse  
of attributes like content, rel, rev.

> 2. Congratulations for inventing CURIEs, but I bet you ought to call
> them CIRIs or COIRIs now, and I bet you ought to define them relative
> to IRIs rather than to URI/Qnames.

Indeed, we will look into basing them on IRIs. Thanks for the pointer.

> 3. If I follow this, the only way to include a 'pure' RDF triple in
> RDF-A is to create an XML <li> element with an id. So all RDF-A
> triples have to have separate XML ids. (??) If so, this seems like an
> unnecessary burden.

It is definitely *not* necessary to use an <li> element, but we  
certainly understand how the Primer may have misled you - all our  
examples use <li>! That's an artifact of how we wrote the Primer, and  
we'll edit it to include some examples that don't require <li>.

Thanks for pointing this out.


> Surely it wouldn't be hard to allow RDF-A to
> include chunks of 'pure' RDF (by which I mean, not explicitly linked
> to ids of items in the XML itself) more or less unchanged from
> RDF/XML, or some other RDF notation in common use? I think this might
> be important for deployed applications, since it would allow RDF/XML
> to be smoothly transitioned into RDF-A, and would also allow RDF-A to
> encode OWL/RDF annotations without incurring a needless notational
> burden. Also, giving an id to a whole RDF (sub)graph fits naturally
> with the 'named graph' idea, unlike giving an id to every triple.


If you would like to include some 'pure' RDF in an XHTML document,  
the right way to do it is to use

<link rel="meta" href="metadata.xml" />

where metadata.xml is a separate RDF/XML resource.

RDF/A is really meant to help augment renderable XHTML with semantic  
information, not to help you include arbitrary RDF/XML straight into  
XHTML. Expressing semantic information that isn't rendered is  
certainly *possible* using META and LINK elements, something like this:

<meta property="dc:title" content="Pat Hayes's comments" />

or

<link about="myphoto.jpg" rel="cc:license" href="http:// 
creativecommons.org/licenses/by/nc/2.0/" />


but it's clear that a large amount of pure RDF would be better  
expressed as a separate RDF/XML document.


> 4. This is probably not appropriate for XHTML, but I can't help
> thinking that it would be really nice (and even more compact) if one
> could use CSS to attach properties and datatypes to spans. Just a
> passing thought :-)

We agree that this isn't in the scope of our task force, but we do  
want to point out that using CSS to express semantic information  
about another document could get confusing. After all, if one wants  
to make an RDF statement about another resource, one should probably  
just use RDF itself, instead of trying to serialize RDF statements  
within CSS. CSS is really for providing style information, not  
semantics.

One issue that is somewhat related and that we're still working on is  
whether the CLASS and/or ROLE attributes within XHTML should be  
syntactic sugar for expressing and rdf:type property.

Thanks for your comments, and please do let us know if our answers  
are incomplete or if they raise more questions.

-Ben Adida
ben@mit.edu

Received on Wednesday, 18 January 2006 23:44:14 UTC