Re: Role of RDFa in 2016

It depends what you mean by RDFa :)  If it's "RDF expressed in HTML", then
it could be in a display:none block with just a simple serialization ala
striped RDF/XML or expanded JSON-LD: terrible for a human to use, but it's
not intended for them. Indeed, they'll never see it.

On the other hand, I agree with Ruben that mixing up presentation and
semantics creates arbitrary constraints that are likely to make both harder
and limit their functionality.  Having it decorate the human readable page
elements /might/ be just changing a template, or it might mean completely
redesigning the site to facilitate the structure.

Rob

On Tue, Oct 4, 2016 at 5:51 AM, William Van Woensel <
William.Van.Woensel@dal.ca> wrote:

> >> I don't see how one can avoid RDFa if we consider WYSIWYG content
> >> (HTML) editing with inline semantic annotations (RDF).
>
> > Just because we edit them that way,
> > doesn't mean we have to publish them that way.
>
> > Ruben
>
>
> Sure, but there are also separate advantages to having *embedded*
> structured data (i.e., embedded in human-readable content), as opposed to
> metadata that is individually available. (client-side) Web augmentation
> relies on gleaning the meaning of page elements, in order to automatically
> enhancing the webpage with all sorts of features (some simple examples:
> making phone numbers on the page "callable" via Skype; looking for a listed
> product on other web shops). For general, non-trivial cases, and on pure
> HTML-CSS webpages, this is a notoriously hard problem to solve. But by
> annotating the page elements with semantics, this becomes a trivially
> simple issue (disregarding issues with ontology heterogeneity, etc.).
>
>
> William
>
>
>
>


-- 
Rob Sanderson
Semantic Architect
The Getty Trust
Los Angeles, CA 90049