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

On Aug 23, 2010, at 14:08 , Richard Cyganiak wrote:

> 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 ...”

o.k.

> 
> 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?
> 

Hm. This is _my_ opinion, may not be the WG's: the answer is yes. 


> 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.
> 

I agree. Removed.

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

I would prefer to leave it. I think that for our authors it would be very complicated to grasp why two things, that are fairly similar in many respect, follow a different syntax approach.

> 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.
> 

Actually, you are right. I always thought of them as being distinct but there is no real reason for that.

> 6. Likewise for term mappings.
> 

Indeed.

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

This is indeed rarely used (probably), it is however a useful mechanism for host languages specific profiles.

See

http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Jul/0134.html


> 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.
> 

Shoot. We already discussed that...

Actually, this of no contradiction, just unnecessary. Indeed, the processing steps defined in this section affect the processing of the corresponding subtree but, well, according to 7.5 the corresponding subtree was not processed anyway. So it was correct just unnecessary. I modified the entry just stating that the handing of the attribute fails and put a reference to 7.5

> 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 ...”?
> 

Actually... I blindly took this from the current document but I really wonder whether this is necessary whatsoever. What we are saying that the default graph of the profile document is the profile graph for the current document. On that level how the profile graph was created (maybe through its own profile documents) is besides the point... I would prefer to ditch it altogether!


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

I added instead a reference to section 6 where this is described.

Ivan

> 
> 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
> 


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