W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > October 2010

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

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Tue, 26 Oct 2010 17:05:53 +0100
Message-ID: <AANLkTikKXSZfWUboBnnUjsCZCoffcP+aNPz9xJv9w6T5@mail.gmail.com>
To: nathan@webr3.org
Cc: Ivan Herman <ivan@w3.org>, Toby Inkster <tai@g5n.co.uk>, public-rdfa-wg@w3.org, Martin McEvoy <martin@weborganics.co.uk>
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
>
>
Received on Tuesday, 26 October 2010 16:07:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:22 UTC