Re: Draft updated

I know we went over these comments in the meeting on Thursday, but just 
to close the loop.  Comments inline:

On 3/2/2011 8:14 AM, Ivan Herman wrote:
> Shane,
>
> Bravo:-)
>
> Some comments below. I have also made some changed on Overview-src, see the list separately below.
>
> ===================
> Comments/questions
>
> 1. There is a reference to the RDFA-PRIMER in the "How to read this document". Alas!, that primer is for RDFa 1.0 and is therefore grossly outdated. I am not sure what to do about it now, because we do not have a primer update:-( but I believe leaving this reference in the document may do more harm than good... I would propose to comment it out.
>
> There is also a similar reference at the very beginning of section 2.

We agreed that Steven would finish updating the primer, so I think these 
references are fine.

> 2. I have a feeling of deja vu, and I am sure we have this somewhere, but I ask nevertheless... The current CURIE definition (Section 6) defined CURIE-s:
>
> curie ::= [[prefix]':'] reference
>
> ie, a pure 'reference', without a colon, is allowed per syntax. Few lines down the line then it says
>
> "the mapping to use when there is no prefix is not defined"
>
> and then refers to TERM processing. Why do we have such a convoluted definition? Why don't we disallow a pure reference as a CURIE and have terms handled separately as they are? It is just way too complicated for my taste...

CURIEs support a 'no prefix' mapping in addition to a 'default prefix' 
mapping.  RDFa does not use this feature.  However, since RDFa is THE 
normative definition of CURIEs, and since there are other consumers of 
CURIEs that might need this feature in the future, we decided to leave 
it along but continue to not use it.

> 3. I wonder whether section 6.1 has any relevance now. This was probably important in previous versions of RDFa when xmlns was used and, hence, this issue did come up. But we do not have that any more, so this section seems to answer a question that nobody, at this point, would ask...

As we discussed, it is relevant because a commenter asked us to ensure 
it was included to explain why we are using a system that is broader in 
scope than QNames.

> 4. Beginning of section 7.2, a slight editorial inconsistency is that, for some entries (parent subject) initial values are defined, whereas for others this is not the case. Although most of those are trival (empty lists and the like) maybe it is worth adding those...

You fixed these.  Thanks!

> 5. Sigh, a problem with the example... there is no such property as dbp:citizenship in albert einstein's dbpedia page, so _all_ those examples are, strictly speaking, wrong!:-( The only way I could solve that is to use the dbpedia-owl:residence property (referring to germany and switzerland). That'd require to add the dbpedia-owl to the list of startup prefixes. I have made those changes, see below.

Thanks!

> 6. In the list of datatypes in 7.4.4, to avoid misunderstanding, it may be worth putting @profile as a separate entry because it allows for a list of URI-s (whereas @vocab does not).
>
> Actually, shouldn't it be TERMorCURIEorAbsURIs for the last item (it is TERMorCURIEorAbsURI right now)?

Yes - good catches.  I have updated this.

> 7. You have a remark in section 9 "@@@@@ the use of the word resource above might be a problem @@@@@". Why is that a problem? At least in RDF terms it is fairly clear... can be a bnode, can even be a URI resource.

Nathan seemed uncomfortable with the term.  Manu has suggested other 
wording, which I think I like.

> 8. This is a comment on the XHTML+RDFa document: the DTD defined for XHTML is
>
> http://www.w3.org/MarkUp/DTD/xhtml-rdfa-2.dtd
>
> shouldn't that be
>
> http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.1.dtd

Hmm... technically, no.  Modularization has a convention for file naming 
that just increments the last digit.  The name of the file has no 
necessary relationship to the version of RDFa that we are supporting.  
You will also notice, for example, that the metainformation module has a 
funny digit suffix.

Having said this, I don't want to be a slave to convention if there is a 
good reason to change it.  Steven, do you have any concerns with going 
away from the convention that we established in M12N ?

> instead?
>
> Also: is that already installed? Ie, can we make use of it already in the various files? At some point we may want to ask the validator to accept it...

It is already installed, works, and the validator works with it as far 
as I know.

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Sunday, 6 March 2011 01:16:30 UTC