Re: Updated editor's draft

Hi Mark,

just some mini-comment on some of the issues. Most of them are now 
settled...

Mark Birbeck wrote:
> Hi Ivan,
> 
> Thanks for your comments--much appreciated.
> 

You are very welcome!

>> Abstract, 4. paragraph, you refer to "RDF Classes and Properties" (in
>> paranthesis). At the minimum I think it should say "RDFS Classes and
>> Properties"; I wonder whether "RDF(S) Classes and Predicates" is not
>> better. (Predicate is the official term term in RDF, as correctly
>> referred to in the RDF terminology section, too). Having said that, RDFS
>> refers to properties in, say, subProperty, so there is an inconsistency
>> there, too... Sigh...:-(
> 
> Yes, I see what you mean. :) Since this doesn't affect the content,
> I've actually replaced the whole thing with this:
> 
>   ...RDFa specifies only a syntax and relies on independent specification
>   of terms (often called vocabularies or taxonomies) by others.
> 

vocabularies, in more complex cases ontologies

(these are the two terms we usually use)

> Is that ok?
> 
>
[snip]
> 
> 
>> 3.6 N Triples: I guess we should be consistent in putting a space (or
>> not) before the closing '.' in each triple.
> 
> Done. I prefer the extra space myself, if that's ok with everyone.
> However, if there is some kind of 'house-style' for this, then let me
> know.
> 

Actually, I usually do not put a space. On the other hand, afaik the 
older grammar of turtle required the space.

The only point is to be consistent.

[snip]

> 
>> 4.3. RDFa Processor Conformance
>>
>> I know we have discussed this before, but the statement on "but these
>> triples MUST be made available in one or more additional RDF [graph]s,
>> and not in the default [graph]." make me a little bit uneasy as an
>> implementer. Essentially: I have no idea what this means, simply because
>> named graphs are not a standardized feature of RDF. I am not sure what
>> to replace this with, but, well, I wonder...:-(
>>
>> (If we have a clear idea what this means, maybe and example would be
>> good, for example)
> 
> Fair point. All we're concerned to say is (a) that no extra triples
> should be present in the default graph, but (b) additional triples MAY
> be made available in some other way, so I've flipped the logic around:
> 
>   A conforming RDFa Processor MAY make available additional triples that
>   have been generated using rules not described here, but these triples MUST
>   not be made available in the default [graph].
> 
> Is that ok? In addition, I've added a paranthetical note to give
> implementers a little clue as to how they might go about this, but
> this is outside of the 'MUST':
> 


I think so. As an implementer I might understand it, for example, as 
implementing an option for the processor; if that option is 'on', I 
could generate additional triples. I think this is covered by this 
formulation.


>   (Whether these additional triples are made available in one or more additional
>   RDF [graph]s is implementation-specific, and therefore not defined here.)
> 
> 

[snip]

> 
> 
>>    - my understanding for the usage of @src in <img> was such that @src
>> should have a higher priority than @instancof, right after @about.
> 
> Yes, you are right. I have verified slightly different rules in my
> implementation than those in the document, which I will work in now.
> Essentially, we need to distinguish between the situation where @src
> has a @rel, and one where it doesn't.
>

Well... I think that is a question/issue to be defined by the group. My 
understanding of Ben's proposal is that @src would behave _exactly_ like 
@about, except having a lower priority. If so, than it does not have 
anything to do with @rel.

This is something the group has to decide.

[snip]
> 
>> Actually... I just wonder whether we need two different objects here.
>> The fact that the [parent object] is a bnode or not is immaterial to the
>> node itself, isn't it? The only point is that, in some cases, the object
>> forwarded from the parent is to be used to complete triples. Is there a
>> different treatment on whether that is a bnode or not?
> 
> I think you are right, but I haven't had time to verify this 100%. My
> previous thinking was that we need to know how we obtained the object
> that is about to be used as a subject, so that we can know whether it
> can be overridden or not. If that's the case, then whether we use a
> flag and one object or have two objects and no flag, makes little
> difference.
> 
> However, it's looking increasingly like we don't have to make the
> distinction; I have a few more tests to run, before I'm certain
> (although the fact that you also seem to be thinking that the
> distinction is unnecessary makes it likely that it's right).
>

:-)

> 
>> 5.4, Processing step, well, general point...
>>
>> I tried to follow through the following edge case:
>>
>> <div about="#A" rel="a:b">
>>    <span rel="q:r"/>
>> </div>
>>
>> My current (may be false!) understanding until now was that no triple
>> should be generated, because the internal 'incomplete triples' (on
>> <span>) never get completed. However, following the current steps, the
>> triple
>>
>> <#A> a:b [].
>>
>> _will_ be generated. Indeed, step 2.3 will set the [new subject] (by
>> virtue of the presence of "q:r" in <span>), and step 3 says that the
>> 'incomplete triples' _are_ generated in such a case, no matter what.
> 
> That's a very good edge-case. I'll look into this some more.
>

O.k, we will come back to that then.

[snip]

> 
>> 5.4, Processing step number 5: I thought that @src does not take part in
>> the determination of current object any more!
> 
> Mmm...but why? I don't recall any discussion that said we should no
> longer support this:
> 
>   <img about="#ivan" rel="foaf:img" src="ivan.jpg" />
> 
> And if we do support it, then all the usual rules should apply.
> 

See my comment above. That is the way I understood Ben's proposal. Your 
example suggests that @src behaves _sometimes_ like @about and 
_sometimes_ like @resource. This is a group decision that I consider 
pending for now...

[snip]
> 
> 
>> Per discussion with Mark it also seems that the intention for
>>
>> - 'bla:'
>>
>> is to be expanded into the corresponding URI from the xmlns declaration.
>> Maybe my reading is incorrect, but the grammar
>>
>> curie :=   [ [ prefix ] ':' ] reference
>>
>> seems to indicate that 'reference' is NOT optional, ie, that 'bla:' is,
>> in fact, incorrect. Do I miss something here? (As far as I am concerned,
>> I do agree with Mark's interpretation for 'bla:', I am just not sure
>> that the grammar is correct).
> 
> I thought I'd replied to this, but since I have a habit of writing
> replies and not pressing 'send', this one may not have gone off. :)
> Anyway, I think the grammar is correct; essentially, 'reference' is
> not optional, but since a relative URI can be empty, you end up with
> the same effect as you are describing.
>

O.k. Fair enough, but making this very clear in the text can help people 
like me:-)

> 
>> However, I still maintain that the exact interpretation of "_:" is
>> somewhat pending and should be decided by the group. Reminder: Mark
>> claims that is should be _one_ BNode (ie, all occurrences of "_:" should
>> refer to the same BNode per document) whereas my claim is that we have
>> the liberty to define this in terms of BNode as we wish by virtue of the
>> semantic mapping of general CURIE-s to the RDFa case, and that it would
>> make sense to have a _different_ BNode for each occurrence of "_:".
>> Either way is, in fact, o.k., not a huge deal, but should be documented...
> 
> My argument was that we don't really have the freedom to define this
> as we like. (Did I really not reply to this already?) 

You did, I replied to you saying that we do have this freedom in my 
view, and this should then be decided by the group:-)

>                                                         We need bnodes
> to exist at the level of CURIEs, and not just at the RDFa level, since
> the whole point of CURIEs is that they will work in other situations
> (such as SPARQL, for example).
> 

SPARQL is actually a good/bad example. My reading of the SPARQL grammar 
is that it does _not_ allow "_:"! Ie, either we can safely ignore SPARQL 
in this argument, or we can _disallow_ this in CURIE if we want a 
compatibility with SPARQL...

I would like to see a usage of CURIE-s outside the RDF realm that has 
such edge case.

Ivan

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf