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

Hi Manu,

Responses inline.

On Wed, Sep 8, 2010 at 12:18 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 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.

Having programmed computers for a few decades now, I have indeed come
across such ideas. ;)

But that's not the point I'm raising here.

It's not unusual to build software in a hierarchical manner, where
module A depends on module B, which in turn depends on module C:

  A -> B -> C

I could happily create module C independently of B and A. Of course I
wouldn't have written the same application as the person who wrote the
ABC application, but if C is all I need it's great that I'm able to do
this.

However, if you then define things in such a way that C depends on A,
then you *must* implement A, B and C:

  A -> B -> C -> A

I can no longer implement C on its own, because it depends on A...and
since A depends on B I have to implement that as well.

This is what we've done by making prefix mappings dependent on a full
RDFa parser.


> 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.

I've never seen this requirement mentioned before. However, it would
still be possible to fulfil this using the other proposal I've made,
which is to have an RDFa document that contains only @prefix, @vocab
and @xmlns attributes.

(I'd still prefer something simpler, but if this criteria is important
I could live with this solution.)


>> #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.

Note that this summary of my position is not quite right, but I dealt
with that in my other response so I won't go into it in too much
detail. The essence though is that I'm not concerned about
internal/external files; my objection is to the use of RDF.


> 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.

With respect...you are really fundamentally missing the point. The
problem is the use of RDF, not the choice of serialisation.

To be honest, I don't find this argument that convincing, because if
the concern was really to not invent something new, why not use text
documents with a format that looks like the N3 @prefix instruction? Or
if the concern was to make the profiles more readable, why not use
RDFa documents, but only process @preifx/@xmlns/@vocab?

But instead what seems to have happened is the use of RDF has become
the defining feature. So the irony is that we /have/ invented
something new -- the use of RDF to express prefix mappings to be used
in an RDF serialisation -- under the guise of not inventing something
new. :)


>> #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.

First, you've not answered the objection though...I didn't say it was
'too complicated to implement', I said it was 'more complicated than
necessary'.

I'd love to see a justification for using RDF to express information
about how to abbreviate an RDF document. (And don't get me wrong --
there may well be some. But if we are going to add this extra layer of
complexity I'd like to see them.)

But second, the current implementers that you refer to are going to be
the equivalent of 'early adopters' in the chasm model. My concern is
that we are preventing novel scenarios from emerging amongst future
implementers (such as my example of an OGP-only parser), because we
require an 'all-or-nothing' approach to implementation.


>> #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.

I thought we had agreed *not* to define warnings and 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. :)

With respect to all involved, the last attempt at a vocabulary (the
error-reporting one) was pretty ropey. You also seem to be forgetting
the reason we decided against producing a vocabulary for
error-reporting which was to do with the amount of time it would take
to get it right.


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

Yes...nothing is as hard as rocket science. :)

But there are plenty of issues, even with this small vocabulary, such
as why are these predicates in the RDFa namespace, why have two
attributes for term *and* prefix, and not just one concept to cover
both, why not use rdfa:vocab instead of rdfa:vocabulary, and more.

So my point remains; why are we so intent on doing this extra work,
when no-one has actually outlined what we gain by using RDF as opposed
to not using RDF?

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Wednesday, 8 September 2010 15:01:09 UTC