Re: Updated Editor's Draft available

Mark Birbeck wrote:
> Hi Ivan,
> 
> Great...thanks for the very useful comments, and for turning them
> around so quickly.
> 
>> A general issue, that I also added to my comments: I wonder whether the
>> spec itself should not be centred around the processing model as the
>> core of the spec, with all other sections being informative. At present,
>> section 7 (the processing model) is labelled as 'informative', ie, all
>> the other sections are informative. I would consider reversing that
>> altogether, and turn the processing model as the normative part, all the
>> rest being informative. In fact, most of the informative part could be
>> reduced a lot, and leave it to the primer (the current text still
>> contains lots of leftovers from the previous versions, as I noted in my
>> comments).
> 
> That's an interesting point. Shane asked me yesterday whether that
> section should be normative or not, and I said that I couldn't see how
> we could make it normative, since it used the idea of recursing
> through a DOM; since I thought we should be able to support other
> processing models it felt wrong to restrict things.
> 
> But I guess with a little work we could resolve that, perhaps using
> some less specific language.
> 

Well _describing_ normatively what happens using the DOM seems perfectly
o.k. to me, if you make clear in the text that this does not require
that it should be implemented using a DOM parser.

You could also describe, I guess, the very same processing using Infosets...

[snip]
> 
> So far, we've agreed that the QNames syntax is incorrect, and also
> that we're going to use CURIEs to give us compact URIs. However, due
> to some people feeling uncomfortable with a a direct link to the CURIE
> spec itself, we've agreed to simply lift the prose and syntax from
> there. This gives us a little flexibility, and makes it not much
> different to recent SPARQL drafts (which now have EBNF for something
> exactly like CURIEs).
> 
> Of course, this means that there will be two specs that are referring
> to something that is exactly the same, and you never know, people
> might decide that referring to the CURIEs spec is not so bad after
> all.

Yes, we need the syntax with ':', you know, the stuff which looks
awfully close to qnames:-) for @rel, etc. I agree. What I really
objected to is to use the href="[a:b]", because @href is defined to use
a URI.

For the syntax for @rel,... well, this is what SPARQL writes in their
spec (after all, they have the same problem):

[[[
Prefixed names

The PREFIX keyword associates a prefix label with an IRI. A prefixed
name is a prefix label and a local part, separated by a colon ":". A
prefixed name is mapped to an IRI by concatenating the IRI associated
with the prefix and the local part.
]]]

and that is it. We could just use a simple text like that for the value
of @rel,... and leave it at that. It does not really need a separate
document! Of course, we have now xmlns and not PREFIX, but it could be
handled as simply as that. We should avoid any overcomplication...


[snip]
> 
>> ------------------------------------------------------------------
>>
>> 3.1 Overview
>>
>> At the very end of the chapter you say:
>>
>> "Specifically, in the case of XHTML2, it makes sense to render as much of the useful metadata as possible and use RDFa to mark up this rendered data. "
>>
>> for 'political' reasons, so to say, I would prefer not to have any reference th XHTML2. RDFa
>> has suffered a lot because people thought that this would be an XHTML2 feature only, and
>> we have to be careful avoiding this image. Actually, I do not believe anyting you say is
>> XHTML2 specific.
> 
> Let's hope the suffering is over...bring me your huddled masses, and
> all that. ;)
> 
> The funny thing is that RDFa was *always* intended to be independent
> of language. Early drafts were incorporated into the XHTML 2
> specification, and as you'd expect, the wording changed to make it
> XHTML 2 specific. I think what happened here is that newer drafts of
> the syntax document took as their starting-point an XHTML 2-specific
> draft rather than a pre-XHTML 2 draft.
> 

:-)


[snip]

>> ------------------------------------------------------------------
>>
>> 4.2. Compact URIs
>>
>> Just making a note again on the bracketed CURIE
> 
> There shouldn't be any bracketed CURIEs, just 'basic' ones.
> 

see my remark above

[snip]

> 
> 
>> The main isssue here, I believe, is that the statement "if a closer ancestor element includes a
>> rel or rev attribute with no href, src or resource, then the subject is the CURIE/URI that
>> corresponds to that parent element" is wrong. The statement (if this is the way we want to
>> describe it) is rather something like "if a closer ancestor element includes a rel or rev attribute,
>> then the object generated by those attribute is used as a subject for this element". But the
>> language used in section 7 is way cleaner...
> 
> I'll be honest, that's what I was really hoping to hear! If everyone
> is happy with the section 7 approach, then I would *much* prefer to
> use it. I don't really like the idea of describing things in terms of
> 'looking for ancestors', and all that. And I also don't like the 'if
> this, then that' descriptions that we have used up until now, because
> it's very easy to miss things when implementing, and it's also quite
> difficult to explain.
> 
> 

let's try to see if this works

[snip]


> 
> 
>> Part 2: isn't there a need for setting the [current resource]? Ie, if there is a @about attribute
>> on [current element], then its value becomes [current resource]
> 
> That's in step 1, where we do anything that can change the evaluation
> context. Part 2 is all about working out what objects you have.
> 
> 

Oops, sorry, I missed that. Right.


>> Part 2, establishing [current object resource]: I think if there is only an @instanceof attribute,
>> that by itself establishes a bnode as a current object resource.
> 
> You're right, and I'm assuming that processors will make all sorts of
> optimisations to the steps I've outlined. But the approach I have
> taken is that regardless of the attributes on an element, you will
> always 'calculate' an object resource, even if you don't end up using
> it.
> 
> So the object resource on an element with @resource, @src or @href is
> the value of the attribute. And if none of those are present, the
> value is a bnode.
> 
> As I say, whether the processor uses that value is another matter, and
> that's where implementers may choose to add some optimisations. But if
> there is an @instanceof attribute, then the object resource is used to
> create an rdf:type, and if there is a @rel or @rev present it is used
> to create a normal triple.
> 
> If a triple is created then our chaining kicks in, which means nothing
> more than saying that the object resource becomes the new 'subject'
> for any nested statements (i.e., it becomes the current resource for
> the evaluation context).
> 
> My view is that this way of explaining it makes it much easier to
> define chaining as simply being caused by @rel, @rev, and @instanceof.
> In our previous explanations we had to say that it was @href,
> @resource and @src that caused chaining...but additionally if none of
> those attributes were present, then you still might get chaining if
> @rel, @rev or @instanceof were present! A lot of if's and but's.
> 

Ah! I see what you mean. And I guess you are right.


> 
>> Part 2, it currently says "If none of these are present then a unique identifier or [bnode] is
>> created.". I think the 'unique identifier' should be ommitted; this could be interpreted as the
>> creation of a URIRef with some sort of a unique URI (like a uuid urn). I think the idea here is
>> to generate a [bnode], that is it. Also, it says "final value of the [current object resource] is an
>> absolute URI," which is not strictly true: it is either a URIRef based on an absolute URI or a
>> blank node.
> 
> Ok, I'll sort that out.
> 
> I was actually going to go the other way, though, and avoid mentioning
> bnodes. All we're really concerned with is creating a unique
> identifier, and we can then provide rules on how that should be done.
> I added "[bnode]" at the last minute just so that you guys knew what
> it was all about. :)
> 
> 

Yes, but if you do not do that, then it is misleading. If you say unique
identifier, that can be a uuid URN! Ie, I do not think the term bnode
can be avoided:-(


>> Part 3, second entry, @instanceof _if value not empty_ (at least that was my proposal, I think
>> we more or less agreed on that)
> 
> I don't recall a discussion on that, although I do remember you
> raising the idea on the list. I'll try to find the thread when I work
> on this tomorrow, but if you have a reference that would be
> appreciated.
> 

It is part of

http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Aug/0028.html

loo for the example beginning with <> foo:bar, and the text before it.
Actually, for @rel and @rev I think the current processing model leads
exactly to that conclusion and, in fact, even for @instanceof. Well,
almost. The current text says:

[[[
One or more 'types' for the [current object resource] can be set by
using the instanceof attribute. If present, the attribute must contain
one or more [basic curies], each of which is converted to an absolute
URI using CURIE processing rules, and then used to generate a triple as
follows:
]]]

which I could read that if @instanceof="" then this is a bug (the text
says 'attribute must contain'. We should probably soften the text by
saying that curie uris are extracted from the attribute value and for
each of them the triples are added. The same for @rel and @rev, actually.

[snip]
> 
> 
>> - I am not sure where we are with the rdf containers and collections. Is this still an open issue?
>> I thought that what we have cleanly fit the rest of the processing model, so we could add it, too,
>> somewhere.
> 
> I think they are easily introduced into the third processing step if
> we decide that they should be in. I thought the status was that they
> would be left until we have this version out of the way. In the
> description I've tried to allow a little room for processors to do
> more processing than is defined here, without being non-conformant.
> 

As I said in my previous mail:

http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Aug/0160.html

one can very well describe some effects as some sort of an abstract pre
and post processing on the DOM and the resulting RDF Graph and achieve
what we need. Maybe that approach works well both for this and the XHTML
predefined property values. That would mean that the core processing
step remains as it is.

Actually, we could use that for the <img> elements, too. Instead of
complicating the processing step we could say that a preprocessing step
adds a @href to each <img> element that with the value of the @src
attribute.

Cheers

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