Re: Ongoing objection to RDFa Profiles format (as XHTML+RDFa)

On 09/08/2010 06:44 AM, Manu Sporny wrote:
> He has one primary objection:
> 
> The RDFa Profile format is expressed in RDF - and that is not good
> design. See the 4 points below for an explanation of why.

Responding to Mark's objections... as I don't agree with Mark's view of
the current RDFa Profiles format.

> #1) We have a software architecture where the foundations depend on the
>     finished product.
> #2) It's not good RDF...it's a pattern that no-one else uses.
> #3) To implement it properly you need to be able to query the triple
>     store.
> #4) We now have to maintain a vocabulary. We have all these terms
>     flying around, have to devise a namespace for them, and so on.
> 
> #1 means that we require an XHTML+RDFa parser in order to parse
> XHTML+RDFa. Mark is asserting that this is bad design and we should use
> a dead-simple format for the RDFa Profile document (perhaps a key-value
> text file - easily parsed by any language, no heavy RDFa requirement).

Speaking generally, there is nothing inherently wrong with languages
that use themselves to alter processing. There are many examples of
languages that use language features to extend their functionality.

Speaking more specifically, while a key-value text file would be
simpler, a major requirement (imho) of the RDFa Profile documents is
that they're human readable. By human-readable - I mean, by a web
designer... not a developer. It would be a shame if an RDFa Profile
document doesn't also include common usage information and documentation
about the terms and prefixes that the document expresses.

> #2 means that no other RDF language refers to an external RDF document
> to modify processing rules. Mark asserts that the external document
> SHOULD NOT be RDF.

Let's say we decide to use a key-value-based text file to express
prefixes and term mappings. The same could be said for that document as
well. The point is that no other RDF language refers to an external
document to modify processing rules... we're in new territory here.

Now, you could say that we shouldn't put ourselves in two new
territories at the same time: 1) external documents that modify
processing rules and 2) external documents that modify processing rules
expressed as RDF.

We've already done #1 and the community seems to agree that it is a good
idea at this moment in time. As for #2, there is a very good argument to
ensure that we don't invent yet another expression format that requires
a new type of parser as well as simultaneously not being human-readable.

> #3 means that the design is more complicated than necessary - requiring
> an RDFa Processor to not only generate triples, but also understand the
> triples that it generates. This is a change from RDFa 1.0, where an RDFa
> Processor only had to generate triples.

I assert that this is not that complicated. Yes, it is a new requirement
of the RDFa Processors... but none of the implementers of this feature
have complained that it is difficult to do, nor processor or memory
intensive.

> #4 means that vocabulary management is a difficult task. Mark asserted
> that he would rather that we not deal with vocabulary management as it
> is often time consuming and difficult to get vocabularies right.

We have to create a vocabulary, regardless of the RDFa Profiles feature.
We need terms for all of the RDFa Processing Warnings/Errors.

Thus, we have already committed to authoring an RDFa Vocabulary. While
it is difficult to get RDF vocabularies right, I would hope that we have
enough expertise in this community to get the job done. If we are
incapable of putting together a usable RDF vocabulary then the semantic
web is doomed. :)

We're really talking about three terms here rdfa:term, rdfa:prefix and
rdfa:vocabulary... it's not rocket science. :)

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: WebID - Universal Login for the Web
http://digitalbazaar.com/2010/08/07/webid

Received on Wednesday, 8 September 2010 11:19:21 UTC