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

ISSUE: Using @id to set subject in RDFa

From: Sebastian Heath <sebastian.heath@gmail.com>
Date: Sat, 19 Nov 2011 13:02:24 -0500
Message-ID: <CACsb_1r18-XZrJK==gyBTHa78dyquMBKRuu8q7QWEQ06HjrGjw@mail.gmail.com>
To: RDFa WG <public-rdfa-wg@w3.org>
Currently, RDFa processors do not take account of @id attributes in
host-languages. In particular, in (x)html the @id attribute is
ignored. In (x)html, this creates unnecessary complication in which
the value in @id needs to be prefixed by '#' and put in an @about
attribute in order to make semantic markup visible to both html agents
and rdfa processors.


 <p id="item1" typeof="ex:item" about="#item1">
   <span property="item_name">An interesting item (1)</span>

 I suggest that a combination of @typeof and @id cause the subject to
be set to the fully qualified URL implied by the value @id, according
to normal URL processing rules defined for HTML and related languages.

 Given a document http://example.org/document1 with appropriate
@vocab/@prefix definitions, this would lead to the markup

  <p id="item1" typeof="ex:item">
   <span property="rdfs:label">An interesting item (1)</span>

 producing the triples

 <http://example.org/document1#item1> rdf:type <http://example.org/ns/item> .
 <http://example.org/document1#item1> rdfs:label "An interesting item (1)" .

 The main advantage is the simplicity of using a single construct to
make semantic data visible to both browsers, DOM aware languages such
as javascript, and to RDFa processors.

 The restriction that the subject is only set when there is also a
@typeof will reduce the number of so-called 'junk' triples. But I note
that RDFa accepts the generation of such triples in other situations
such as link elements invoking style sheets using @rel.

 It may be that this functionality is best defined for particular host
languages and not in the RDFa 1.1 core.

 Sebastian Heath.
Received on Saturday, 19 November 2011 18:02:53 UTC

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