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

Ivan,

Thanks for taking the time to address my comments!

On 23 Aug 2010, at 14:52, Ivan Herman wrote:
>> 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.

May I suggest wording along the lines of: “When the protocol used for  
accessing the profile document supports delivery in multiple  
alternative formats, then the profile document may also be defined in  
other RDF serializations in addition to HTML+RDFa.”

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

Fine with me either way.

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

I understand the default vocabulary mechanism, but I don't understand  
how they are expressed in a profile document. I believe the intention  
is something along these lines:

<http://example.com/my-host-language#> rdfa:vocab ??? .

The default vocabulary URI goes into the subject. But what goes into  
the object?

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

Ok, thanks, I'm happy with this wording.

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

I think you are right, this exception isn't strictly needed any more.  
I'm not sure though that I like the possibility of arbitrarily deeply  
nested profile document structure (including potential infinite  
nesting loops). I'd feel better if there was AT LEAST some language  
along these lines: “To avoid latency and recursive nesting problems,  
profile document authors SHOULD NOT use the @profile mechanism inside  
profile documents.”

>> 10. There should be a sub-section on default profiles.
>
> I added instead a reference to section 6 where this is described.

I see a reference for default vocabulary URI, but what I meant was  
profiles (incl. term and prefix mappings) pre-defined by the host  
language.

Best,
Richard



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

-- 
Linked Data Technologist • Linked Data Research Centre
Digital Enterprise Research Institute (DERI), NUI Galway, Ireland
http://linkeddata.deri.ie/
skype:richard.cyganiak
tel:+353-91-49-5711

Received on Tuesday, 24 August 2010 12:15:20 UTC