Re: Pointing out content for properties

> On Sep 19, 2016, at 6:17 AM, Andrea Rendine <master.skywalker.88@gmail.com> wrote:
> 
> Greetings to everybody.
> 
> I wrote to this mailing list some time ago, with the proposal of
> integrating <iframe@srcdoc> and <data@value> into RDFa mapping model.
> This would allow RDFa processors to read these attribute as property
> content, instead of the default behaviour (@src and content
> respectively). The first case was not so common, while for the second
> I was offered a deep insight of the real issues for such a scenario by
> Manu Sporny himself.
> 
> Essentially, as RDFa is not meant for HTML only, but for a variety of
> languages, it would be a bad choice to support a myriad of specific
> cases for specific elements in specific languages. The problem with
> <data@value> is also that the value attribute is used in several
> elements (e.g. <li> in ordered lists, form controls), so the
> interpreter should be integrated with the rule "read the value
> attribute in the data element, but not anywhere else". Consistency is
> greeting from afar, I know.
> 
> RDFa is sensitive to the subject of specific content, in fact it is
> possible to specify that the content of a property should not be the
> text node concat, but the markup as a whole
> (datatype="rdf:XMLLiteral") or an entirely different string
> (content="alternative content").
> 
> The problem is, in the latter case the alternative content is already
> there, hidden in other attributes which can have a semantic on their
> own. This is true for both HTML and XML. And RDFa cannot know it in
> advance. XML can have the strangest element/attribute assets, while in
> HTML WG there's a small but growing voice about custom elements. In
> addition to this, sometimes the choice of considering content instead
> of attributes could be ambiguous.
> 
> I don't know whether there still is a RDFa WG

(There’s not, nor is there a relevant CG right now).

> , but in case there is a
> project for future versions, this is my proposal:
> 
> A new attribute could be defined in RDFa. It should be in the "Lite"
> flavour of the language, so that it could be used in the core version
> as well. This attribute, let's call it "context", could specify which
> part of the DOM defines the @property content, also overriding
> default. This could also absorb the case where not only the plain
> literal text content is to be considered, but the whole xml/html
> subtree:
> - <data property="amount" context="attr(value)"
> value="-1234">(1,234)</data> this defines the content of @value as
> reference value for amount, instead of text content (where the
> negative number is represented in a sector-specific notation and with
> a local K separator)
> - <a property="fullName" context="content(text)"
> href="/profiles/foo_mcbar">Foo McBar</a> tells the interpreter to look
> at the text content of the <a> element instead of considering the
> external resource(note: this can be currently achieved in other ways,
> such as <a href="/profiles/foo_mcbar"><span property="fullName">Foo
> McBar</span></a> and it's just an example)
> - <div property="performance"
> context="content(XML)"><table><tr><th>2014</th><th>2015</th></tr><tr><td>+100</td><td>-200</td></tr></table></div>
> instructs the interpreter to consider the whole table as content for
> "performance" property.
> - without the context attribute, the default behaviour applies (i.e.
> take the resource if specified and the content otherwise).

The tract we’ve taken in RDFa is to define such context-sensitive definitions to be compatible with the underlying markup. In the case of HTML5, the content model already defines which attributes should be used, and datatypes applied. The HTML5+RDFa 1.1 Spec [1] defines specific processing rules to align with HTML5’s notion of semantic meaning of elements, such as <data>, <time>, and @datetype. The Microdata to RDF spec [2], in it’s most recent edition, goes further to discuss more elements (e.g., <meter> and <meta>). As most use of RDFa is by non-experts, mimicking schema.org examples, I think staying simple, and depending on the semantics of the underlying markup language; perhaps a group should be chartered to look at revising the HTML5+RDFa 1.1 Spec in light of HTML5.1.

While you’re @context proposal certainly allows more specificity, it comes at the cost of requiring more expert knowledge of users, which many regard as a shortcoming of RDFa already. At this point, I think it unlikely that RDFa Core 1.1 will be revisited anytime soon, or at least until users value inline markup vs. adding specificity through <script> and embedded JSON-LD.

That said, if there is another XML-derived markup for which syntactical structures with semantic meaning could benefit from a host-language-specific version of RDFa 1.1, it would be useful for such groups to define RDFa-specific rules, along the lines of HTML5+RDFa 1.1.

> This would make some situations easier to maintain and would allow the
> semantic of HTML to be even more semantic, leaving authors deal with
> use cases.
> 
> Is this possible to achieve? I hope to receive some feedback.
> 
> Andrea Rendine
> 

(just my $0.02)

Gregg

[1] http://www.w3.org/TR/html-rdfa/#additional-rules
[2] http://www.w3.org/TR/microdata-rdf/#dfn-property-value

Received on Monday, 19 September 2016 18:25:01 UTC