Re: Some RDFa 1.1 Core edge cases that we need to clarify

I agree with Mark here.  However, I also feel that we should encourage 
people to NOT do this for the same reasons we encourage people to not 
use relative URIs for prefix mappings.

Also, and correct me if I am wrong, don't we need to fully resolve any 
relative URIs in order to implant them in attributes within an 
XMLLiteral serialization?

On 10/26/2010 11:05 AM, Mark Birbeck wrote:
> Hi Nathan,
>
> As you and others have said, there is no problem here.
>
> But note also that the processing your refer to is already well
> described in the spec, at the top of section 7.4 'CURIE and URI
> Processing':
>
>    Since RDFa is ultimately a means for transporting RDF, a key concept
> is the resource
>    and its manifestation as a URI. RDF deals with complete URIs (not
> relative paths); when
>    converting RDFa to triples, any relative URIs must be resolved
> relative to the base URI,
>    using the algorithm defined in section 5 of RFC 3986 [URI],
> Reference Resolution.
>
> This means that whatever value is yielded by concatenating a term with
> the value in @vocab will be sorted out correctly when the combination
> is processed in relation to the base URI.
>
> The flip-side of that is that no special processing is required to
> manage @vocab, other than to store it, and then perform concatenation
> of an unrecognised term is spotted. In other words you don't need to
> resolve the URI in @vocab -- just use it as a prefix. This is in fact
> what the text already says in the second bullet of section 7.4.3
> 'General Use of Terms in Attributes':
>
>    Otherwise, if there is a local default vocabulary the URI is
> obtained by concatenating that
>    value and the term.
>
> However, since relative URIs in @vocab has caused some confusion it
> might be an idea to add a note somewhere about their use. I'd suggest
> the end of section 7.4.3, with wording along the following lines:
>
>    Note that as described at the top of this section all URIs are
> resolved against the base URI
>    before being used to generate triples. This means that even relative
> URIs can be used to
>    define a default vocabulary.
>
> Regards,
>
> Mark
>
>
> On Tue, Oct 26, 2010 at 4:21 PM, Nathan<nathan@webr3.org>  wrote:
>> Ivan Herman wrote:
>>> On Oct 25, 2010, at 17:45 , Toby Inkster wrote:
>>>
>>>> On Mon, 25 Oct 2010 13:15:44 +0100
>>>> Martin McEvoy<martin@weborganics.co.uk>  wrote:
>>>>
>>>>> The second vocab attribute "2#" would resolve to
>>>>> http://example.com/base2#which may be wrong?
>>>> No, that's not how base works. Check this in a browser:
>>>>
>>>> <html>
>>>> <base href="http://example.com/base">
>>>> <a href="2#">hover over this link, look at status bar</a>
>>>> </html>
>>>>
>>>>> I think @vocab should always be an absolute URI (easier to parse an
>>>>> less complicated)
>>>> We already need to support relative links in @about, @resource, @src
>>>> and @href, so supporting relative URIs in @vocab is not too much to ask
>>>> from a parser.
>>>>
>>>> Actually, re-reading the RDFa Core 1.1 spec, it seems we already allow
>>>> @vocab to be relative (or at least we don't seem to forbid it
>>>> anywhere). If so, then it seems my concerns are unwarranted, and
>>>> vocab="2#" is well-defined.
>>> That was my reading of the document, too. It is a URI, that can be
>>> relative. I do not think we have a problem here.
>> Likewise, I see no problem - every URI/IRI(-Reference) can (should) be
>> passed through a function which resolves it against the base prior to use.
>>
>> The algorithm [1] is well defined in RFC 3986 [URI], pointed to for usage by
>> RFC 3987 [IRI], handles everything from absolute through to fragments, and
>> is implemented in almost every environment where you find a URI.
>>
>> Thus all things considered, I don't see why one attribute (@vocab) should be
>> treated specially when best/current practise is to resolve all URIs that
>> appear anywhere in a document prior to usage.
>>
>> [1] http://tools.ietf.org/html/rfc3986#section-5.2.2
>>
>> Best,
>>
>> Nathan
>>
>>

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Tuesday, 26 October 2010 16:19:03 UTC