Re: Format of @profile files (summarizing ISSUE-39, maybe moving forward...)

On 23 Aug 2010, at 12:17, Ivan Herman wrote:
> I have tried to come up, therefore, with an alternative text to the  
> current description of profile files in the document, ie, section  
> 9[4]. I have put an alternative text to the Wiki[5]; it would be  
> nice if you guys could look at the text to see if it is all right as  
> an alternative or not. We could then try to close this issue on one  
> of our forthcoming telcos. (Note that the examples and the official  
> XHTML profile file would have to be rewritten, too, but that becomes  
> easy.)
>
> Thoughts?

Some comments on [5]:

1. For clarity, I would re-order the sentences in the first paragraph:  
“Profiles are external documents ... They are referenced via  
@profile ... They must be defined in an approved host language ...”

2. “They may also be defined in other RDF serializations as well” --  
What's the intent here? That such other serializations are provided as  
alternatives via content negotiation?

3. The Note about “triples must not be co-mingled” seems to be  
unnecessary now, the language in the following points makes it  
sufficiently clear IMO.

4. Personally I wouldn't mind if the current, literal-based method for  
establishing *prefix* mappings stayed. That being said ...

5. “If another triple using the rdfa:prefix predicate is present in  
the profile graph with either the same subject or the same object,  
disregard this mapping.” The mapping should just be disregarded if  
another same *subject* is present. There is no problem with  
associating the same URI with multiple prefixes.

6. Likewise for term mappings.

7. Can you give an example for the intended use of rdfa:vocabulary? I  
don't understand it.

8. The processing rules for the case that a profile document is  
unavailable are unclear to me. Here it simply says, “skip and continue  
with the next profile URI”. Elsewhere (7.5) it says: “If any  
referenced RDFa Profile is not available, then the current element and  
its children must not place any triples in the default graph.” And  
(7.6): “An ERROR must be generated when an RDFa Profile document fails  
to be retrieved and thus, a portion of the document fails to be  
processed.” I don't understand why processing of profile documents  
continues if no triples will be generated from the subtree.

9. The Note at the end of the proposed text seems to state an  
exception to the earlier statement: “... parse the retrieved content  
as an RDFa document ...”. Maybe the Note can be converted into a  
qualifying statement on that sentence? “... parse the retrieved  
content as an RDFa document, except that any @profile within the  
content is ignored ...”?

10. There should be a sub-section on default profiles.

Best,
Richard

> [4] http://www.w3.org/TR/2010/WD-rdfa-core-20100803/#s_profiles
> [5] http://www.w3.org/2010/02/rdfa/wiki/ProfileSpec

Received on Monday, 23 August 2010 12:09:23 UTC