RE: Updated RDFa 1.1 Core editor's draft

A) Where can I see ISSUE-133?

B) Again, I can only compare this document to the one posted at
http://www.w3.org/TR/2012/CR-rdfa-core-20120313/. However, it appears that
the big changes in this document are the addition of @about and (if in
<root> : [base]) as possibilities in Section 7.5, Step 5.1, for when
{@typeof}. Is this correct?

C) The effect of this change seems to be as follows:

C.1) In the previous version the only difference between what I call "{@rel
| @rev} Mode" and "Special Property Mode" was that, in the latter, a new
bNode could be created for use as a [typed resource] regardless of {@about}
(see my table at
http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Apr/att-0013/RDFa_Sub
ject-Object_Variables_Determination.pdf in footnotes 6 and 9.).

C.2) In this version:

C.2.a) In "Special Property Mode," a new bNode cannot be created for use as
a [typed resource] if {@about} simply because @about is earlier in the list
of possibilities. So this behavior now matches the behavior when in "{@rel |
@rev} Mode," though via a different algorithm.

C.2.b) However, now - when in "Special Property Mode" - it is entirely
possible for [current object resource] to be set to *@about because @about
is now in the list of possibilities for assignment to [typed resource] ...
AND ... [current object resource] is set to the value of [typed resource]
after all is said and done. Is this the intention? Did you really mean to
create a situation wherein it is possible for [current object resource] ==
*@about? In fact, this creates two situations wherein [new subject] ==
[current object resource]. Is that the intention? Except for some very
special situations (such as: <myprefix:Grant> foaf:knows <myprefix:Grant>.),
this could lead to some very confusing triples.

C.2.c) Also, - when in "Special Property Mode" - it is now possible for
[typed resource] to be set to [base], which is impossible in "{@rel | @rev}
Mode." Is this the intention? What would be the purpose of this difference?


D) If the actual intention was to make it so that the final values for [new
subject], [current object resource], and [typed resource] come out the same
for both modes: "{@rel | @rev} Mode" and "Special Property Mode," then why
didn't you just write the algorithm to say, "If {@rel | @rev} OR (!{@rel |
@rev} BUT ({@property} & !{@content | @datatype})) THEN DO X, Y, & Z (or
simply copy and paste one algorithm to two places in the document) rather
than make up these similar but different algorithms?


It seems to me that, if the desired result was to allow for a special use of
@property wherein it worked exactly the same as @rel, then 1) you have gone
a very long and circuitous route to - almost but not quite - get there, and
2) I really don't see the point. If the desired goal is to make @property
work exactly the same as @rel except you wanted to allow [current object
resource] == [new subject] then I REALLY don't see the point. Pardon me for
being blunt. Perhaps I would understand better if I knew what the end goal
of this whole "Special Property Mode" was, in plain English.


Thanks,
Grant

P.S. As defined in my "Subject-Object Determination Table" (at
http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Apr/att-0013/RDFa_Sub
ject-Object_Variables_Determination.pdf), "Special Property Mode" is nothing
more than the special situation wherein !{@rel | @rev} BUT ({@property} &
!{@content | @datatype}) that the algorithm gets to in Section 7.5, Step
5.1. If you give a concept or situation a name then it is easier for people
to talk about.

P.P.S. Oh yeah, "if in <root> : [base]" is just a shorter, more direct way
of saying "if the element is the root element of the document, then act as
if there is an empty @about present, and process it according to the rule
for @about, above." 


> -----Original Message-----
> From: Ivan Herman [mailto:ivan@w3.org] 
> ...
> I have updated the 
> editor's draft of the RDFa 1.1 Core:
> http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html
> that reflects the changes necessary to solve ISSUE-133
> The changes are in section 7.5, step 5.

Received on Friday, 6 April 2012 06:04:14 UTC