- From: Shane McCarron <shane@aptest.com>
- Date: Mon, 18 Oct 2010 16:02:15 -0500
- To: Gregg Kellogg <gregg@kellogg-assoc.com>
- CC: Manu Sporny <msporny@digitalbazaar.com>, RDFa WG <public-rdfa-wg@w3.org>
- Message-ID: <4CBCB5D7.4090608@aptest.com>
Gregg,
My comments in-line as I addressed your feedback:
On 10/12/2010 8:01 PM, Gregg Kellogg wrote:
> This review is based, in part, on comments I gave in previous requests
> for clarification, and where there is some confusion remaining in my
> own implementation.
>
> *General observations*:
>
> RDFa 1.1 introduces some incompatibilities with RDFa 1.0, and these
> should be specifically called out. Some direction could also be given
> to implementors who choose to support both RDFa 1.0 and 1.1 semantics
> (say, through a runtime argument). In general, the points of
> difference are minor, and can be accommodated reasonably easily by a
> parser. One that comes to mind is that SafeCURIEorCURIEorURI can be
> mapped to different requirements for 1.0 and 1.1, but
> TERMorCURIEorAbsURI is sligtly different depending on if it's used in
> @property or @rel/r@rev/@typeof/@datatype. These are the mappings I
> use in my implementation:
>
> SafeCURIEorCURIEorURI = {
> :rdfa_1_0 => [:term, :safe_curie, :uri, :bnode],
> :rdfa_1_1 => [:term, :safe_curie, :uri, :bnode, :curie],
> }
> TERMorCURIEorAbsURI = {
> :rdfa_1_0 => [:term, :curie],
> :rdfa_1_1 => [:term, :curie, :absuri],
> }
> TERMorCURIEorAbsURIprop = {
> :rdfa_1_0 => [:curie],
> :rdfa_1_1 => [:term, :curie, :absuri],
> }
I have introduced an appendix to cover the changes. Interesting the way
you approached your implementation. I did it quite differently - I have
a datatype defined for each attribute for each mode.
>
> Section 2.2 introduces "terms" without referencing or defining it.
> Term is an important concept, and should probably be introduced before
> examples that use it:
>
>> A simple way of defining a portion of a document to use FOAF terms is
>> to use @vocab <http://www.w3.org/TR/rdfa-core/#dfn-vocab> to define a
>> default vocabulary URI:
>>
>> <divvocab="http://xmlns.com/foaf/0.1/" about="#me">
>> My name is<spanproperty="name">John Doe</span> and my blog is called
>> <arel="homepage" href="http://example.org/blog/">Understanding Semantics</a>.
>> </div>
> Same thing for "prefixes":
>
>> RDFa also permits external definition of collections of prefixes. The
>> following RDFa Profile document, residing
>> at|http://www.example.org/vocab-rdf-dc.html| defines the standard RDF
>> prefixes as well as the Dublin Core vocabulary prefix in
>
I am loathe to restructure the document at this point to try to define
things before the examples. The group made a conscious decision years
ago that it was more important to get to the meat of what you can do
than to introduce the reader to every concept up front. I have,
however, ensured that when we are referencing concepts that we DO
define, these are linked so it is easy to drill down if you want to.
> Section 6. Many readers will be familiar with a QName, but not a
> CURIE. At first glance, they seem much the same. It would be useful
> having a note describing why CURIE and not QName, and a brief
> description of where they diverge, for instance extracted from
> [CURIE]. Of course, the spec should also reference [CURIE]:
> http://www.w3.org/TR/2009/CR-curie-20090116/
Actually, the spec shouldn't reference CURIE. That spec is dead (I will
issue a W3C Note one of these days, but it is no longer rec track
apparently). I have grabbed a little text from there. However, note
that the CURIE part of this spec is quite similar to the way it was in
1.0. We don't want to change it too much - this is the basis for the
definition of CURIE as used in other W3C specifications.
>
> Section 7.4. I believe the spec is too permissive over what can be a
> URI. Basically, anything that is NCNAME ':' ... is treated as am
> AbsURI (which isn't really well defined, either). I believe that there
> should be some other mechanism, for instance a white-list of schemes,
> that is used to validate potential URIs. Far too often, as a result of
> one problem or another, I find <dc:title> emitted, when it should be
> dc:title as a CURIE. Simply leaving out a necessary prefix mapping can
> go undetected, where in RDFa 1.0, it would have generated a processor
> error.
The working group has discussed this length, but in the end could not
reach consensus on a way to make this mechanism more strict.
>
> Section 7.4.3. There is still some open issue on if Terms are
> downcased, case-insensitive or something else (i.e., the
> "agent"/"Agent" issue).
The working group is still considering this, but it will get clarified.
>
> Section 7.5 step 11. Production causes one or more literals to be
> generated through multiple predicates, but language says "Once the
> triple has been created".
This text as been removed. The spec no longer has a 'recurse' flag.
>
> Section 8.1.1.5 has a couple of sub-sections, which are too deep to be
> either included in the table of contents, or properly marked as a
> section. Consider reducing the section scope somehow, to allow these
> to be properly rendered.
>
Fixed
> Within 8.1.1.5 "Inheriting an Anonymous Subject". I think this was
> brought up on the list, but saying "An RDFa Processor _will_ generate
> the following triples" in a normative section should probably use MUST
> or MAY. With regards to BNodes, will or MUST is confusing, given
> parser flexibility in generating BNodes, and the irreproducibility of
> any given BNode identifier.
It turns out there was a lot of discussion about this. I do not have a
clear sense of what the working group wants said in the document at this
point. Basically, an RDFa Processor can generate any bnode identifiers
it wants, so MUST isn't right, but MAY implies it might not generate
anything at all...
>
> On a purely technical note, I think that it's great that the document
> uses RDFa to mark itself up.
>
> * I note that the format declares a prefix dcterms:
> http://purl.org/dc/terms/ whereas the body of the document uses
> dc: ttp://purl.org/dc/terms/. This is, of course, correct, but
> somewhat inconsistent.
>
Actually, I think we use dcterms: everywhere. I could not find the
string 'dc:' in the source.
> * It's great that you actually provide references to resolutions
> within the document, but the references do not actually tie back
> to the sections they come from. For example:
>
>
> <http://www.w3.org/TR/rdfa-core/#C1> bibo:affirmedBy
> <http://www.w3.org/2010/02/rdfa/meetings/2010-05-20#resolution_1> .
>
>
> There should also be the following, to relate the resolution to the
> chapter it contains, perhaps using bibo:annotates or dc:isPartOf
>
> <http://www.w3.org/TR/rdfa-core/#C1> a bibo:Note, bibo:LegalDecision;
> bibo:annotates <http://www.w3.org/TR/rdfa-core/#white_space>;
> bibo:affirmedBy
> <http://www.w3.org/2010/02/rdfa/meetings/2010-05-20#resolution_1> .
>
>
> (Even more, normative sections should probably also be a
> bibo:LegalDecision, in addition to bibo:Chapter).
>
> Still these are real nits that no one but this audience is likely to
> ever come across.
Well... I want the embedded RDF to be as useful as possible. I will put
my head together with Manu and see if there is something we can do.
>
> Gregg
>
> On Oct 10, 2010, at 7:51 AM, Manu Sporny wrote:
>
>> We are scheduled to take RDFa Core 1.1 into Last Call at the end of
>> October (that's in roughly two weeks). To those of you that are not
>> familiar with the term "Last Call", it's effectively a feature-freeze on
>> RDFa 1.1. The only changes that are kosher after Last Call are editorial
>> changes (in general, no new features are allowed).
>>
>> In order to be fairly sure that we have a document that we're
>> comfortable with taking to Last Call, we need a few people to review the
>> RDFa Core 1.1 Last Call document and send in their comments.
>>
>> You don't have to have any special prior experience with RDFa to review
>> the document. A mix of people that have never read the document fully
>> and those that understand RDFa 1.0 thoroughly would be good.
>>
>> Could a few people step forward at this point and volunteer to review
>> RDFa Core 1.1 before we go to Last Call? The review would have to be
>> done before the end of the month, reviewing the currently published
>> document should be fine (as long as you understand that there will be a
>> few minor changes that go into the document in the next few weeks):
>>
>> http://www.w3.org/TR/rdfa-core/
>>
>> -- manu
>>
>> --
>> Manu Sporny (skype: msporny, twitter: manusporny)
>> President/CEO - Digital Bazaar, Inc.
>> blog: Saving Journalism - The PaySwarm Developer API
>> http://digitalbazaar.com/2010/09/12/payswarm-api/
>>
>
--
Shane P. McCarron Phone: +1 763 786-8160 x120
Managing Director Fax: +1 763 786-8180
ApTest Minnesota Inet: shane@aptest.com
Received on Monday, 18 October 2010 21:03:04 UTC