W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > January 2011

RDFa Core Review: RDFa Profiles

From: Jeni Tennison <jeni@jenitennison.com>
Date: Thu, 6 Jan 2011 13:53:49 +0000
Message-Id: <8FD79DA4-F4EB-4049-B650-DFCDAFA4A5A1@jenitennison.com>
To: W3C RDFa WG <public-rdfa-wg@w3.org>

Reviewing the RDFa Core Last Call Working Draft at:


some specific comments around RDFa Profiles.

(Ed) Section 2.2 Examples: When profiles are first introduced here, I think it would be helpful to:

  (a) use typeof="rdfa:PrefixMapping" or typeof="rdfa:TermMapping" rather than the slightly obscure typeof=""
  (b) provide an example of the RDFa Profile in Turtle, so that it's clearer what RDF triples it contains
  (c) be explicit about the assumption of content negotiation of some kind that means that requests to http://www.example.org/vocab-rdf-dc will result in the RDFa document at http://www.example.org/vocab-rdf-dc.html

(Tech) Section 4.2 Host Language Conformance says:

> The Host Language may define a default RDFa Profile. If it does, the RDFa Profile triples that establish term or URI mappings associated with that profile must not change without changing the profile URI. RDFa Processors may embed, cache, or retrieve the RDFa Profile triples associated with that profile.
> Note: Host Languages are required to change the URI of their default profile if items are added or removed from the default profile document. The URI change is required to accomodate RDFa Processors that statically embed the terms defined in the profile. Host Languages are expected to change their profiles very rarely.

Will this restriction cause problems for HTML5 + RDFa given that HTML5 says that the rel attribute may take values defined in http://wiki.whatwg.org/wiki/RelExtensions, which is not going to be static and may change very rapidly? Or will the profile for HTML5 set a default vocabulary and thus possibly interpret NMTOKENs that should be ignored as CURIEs?

Section 9 RDFa Profiles:

(Ed) 1st paragraph: For all that it's been developed by members of the RDFa WG, I don't think it's appropriate to call out JSON-LD as a particular syntax for RDF. Given that there are so many syntaxes available, I think it's reasonable to restrict the ones you list to those that are currently published by the W3C.

(Ed) Step 4 says:

> For every extracted triple that is the common subject of an rdfa:prefix and an rdfa:uri predicate, create a mapping from the object literal of the rdfa:prefix predicate to the object literal of the rdfa:uri predicate.

I don't think that triples can be subjects of the rdfa:prefix or rdfa:uri predicates (unless you're getting into reification). I think it should be reworded to something like:

  "For every resource that is the subject of a triple with a rdfa:prefix predicate and a triple with a rdfa:uri predicate, create a mapping from rdfa:prefix object literal of that resource to the rdfa:uri object literal of that resource."

(Ed) Step 5 similarly.

(Tech) 4th paragraph says:

> If any conflict arises between two RDFa Profiles associated with URIs in the @profile value, the declaration from the RDFa Profile associated with the left-most URI takes precedence.

In general, profiles that are processed further down the tree (encountered later) override those that are specified further up the tree (encountered earlier). It seems a bit weird that within an individual @profile attribute this precedence is reversed, such that profiles that are encountered *earlier* in the attribute override (or take precedence over) those that are encountered *later*. I would have anticipated that the right-most URI would take precedence.

(Tech) Appendix B: The RDFa Vocabulary for Term Assignments declares rdfs:ranges on the rdfa:prefix (xsd:NMTOKEN), rdfa:term (xsd:NMTOKEN), rdfa:uri (xsd:anyURI) and rdfa:vocabulary (xsd:anyURI) properties. However, none of the examples in the rest of the spec use datatypes. Should the rdfs:ranges be removed? I think it should be made clear in Section 9 that the values of these properties must be plain literals, if that's the intention.


Jeni Tennison
Received on Thursday, 6 January 2011 13:54:22 UTC

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