Re: Role of RDFa in 2016

On 2016-10-03 22:31, Kevin Ford wrote:
> Dear All,
>
> Although I feel like I will be flamed for this question, I was
> interested in hearing some opinions about the role of RDFa vs JSON-LD
> (embedded in the HTML header, let's say) in HTML now that the latter has
> become more accepted, at least when it comes to one major search engine.
>  Has that weakened the use case for, or role of, RDFa?
>
> To ask a broad question: Who/What consumers make regular use of RDFa
> (because there is no alternate/easy serialization to obtain)?
>
> To ask a slightly more targeted question, if you publish a data service
> that responds to content-negotiation (and which can embed JSON-LD in the
> header and which can also provide rel="alternate" links in the header),
> is it reasonable to conclude that RDFa is overkill in such a scenario?
>
> I recognize the use case for RDFa is much deeper than search engines,
> but I also suspect that in most cases when a service publishes RDFa in
> the HTML, that same service likely has made a 'cleaner' alternate
> serialization available.
>
> --Kevin
>
>

Great inquiry. Thanks for raising it. I'll give it a shot.

It is the RDF language that matters, the rest is just details =)

I think using the "right" RDF format is generally about optimisation and 
user experience. It would be premature to think that one format is 
ultimately better than the others without considering all the variables.

RDFa can be complicated to work with, but it has its rewards. In my 
experience, some of those rewards are not fully tapped into just yet. We 
haven't completely designed interactions that makes the best of 
HTML+RDFa. That's both for the publishers as well as the consumers.

On the surface, HTML+RDFa provides the possibility where a single 
resource can be both human and machine-readable. If the content is prose 
in nature or the system has a user interface, it is able to exist in an 
environment where the user can read, write, execute out of the box so to 
speak. It extends the current Web with the least machinery in place. 
Less moving parts the better. The simplest designs tend to win in the 
long run.

When we dig deeper, we soon find ourselves in a situation where we have 
to in fact get a lot of the plumbing done to have all this work 
seamlessly. This is actually a difficult challenge to address on the 
whole Web stack. After all, HTML+RDFa doesn't exist in a vacuum. It has 
to co-exist in an environment where both the server and client is or can 
act on it.

I think it is not so much about the particular RDF format but what 
people can do with it. New formats are picked up through time to address 
different use cases, environments, and for historical reasons. If one 
has the machinery to publish one or more formats with a particular 
configuration, and have it be consumed as desired to its potential, who 
is to say otherwise?

If some data can have a user interface, it probably ends up going 
through HTML sooner or later. The question then is, do we want to bridge 
or narrow down the gap between human and machine reading, or are we 
striving for ways to optimise each in their own way? This is probably a 
more difficult and interesting question to answer.

-Sarven
http://csarven.ca/#i

Received on Tuesday, 4 October 2016 05:43:46 UTC