Re: RDFa with multiple CURIEs as property..

Hi Dan,

> May I suggest that 'fork' is needlessly emotive language here?

We're all adults. I think we can have discussions without being forced
to have meta-discussions all the time.

In this case I believe the word 'fork' to be correctly used. If you
create a new version of something that already exists (when the ink is
still wet, no less), a fork has been created. Also, the word is one
that will be familiar to people who work within the open-source
community.

(In passing, I note that in another discussion you object to someone
using the term "URI crisis". With respect, telling people what words
they should use, or indeed how they should think, rarely ends well,
and can stifle discussion.)


> Creating and maintaining a full-featured human-friendly editor for all of
> RDFa is a non-trival undertaking.

That's not really the subject of this topic. But I think it's
reasonable to say that most of the interesting software engineering
problems you would want to solve today are non-trivial.


> Many many tools will allow people to use
> some application, and will then expose some constrained chunks of data using
> RDFa. For example, a social network site that keeps all its info in some SQL
> database, or a desktop app that has its own on-disk representation (XML or
> whatever). If any of these folk publish through RDFa, this is a wonderful
> thing. And if OO/ODF do this, it's wonderful thing too. We should be happy,
> regardless of the on-disk or backend data representation.

I do apologise, but I'm not following you. What has the back-end
storage to do with this discussion? We're talking about a mark-up
language that is importing a subset of RDFa into it, rather than the
entire language. The backend can indeed be anything anyone wants.


> However the hope here is that these office tools/specs can go further, and
> make more 'native storage' use of RDFa, ideally in its entirety. Whether
> that makes sense for the various stakeholders depends on a huge network of
> factors. It is perfectly reasonable to choose to use a subset of RDFa within
> some application context.

I may have misunderstood you, but I think using a subset in an
application is different to using a subset in a language.

I'll illustrate.

If I were to create a Drupal module that automatically added RDFa to
every node that was published, in order to reflect the value of each
taxonomy term, then it is true I would be entitled to use as little or
as much of RDFa as I like; any *consumer* of my mark-up would still be
able to extract the triples.

However, if I was creating a language (or modifying an existing
language, such as SVG or SMIL), and I said that I was going to import
*most* but not all of RDFa, then I think that would be wrong.

It would be wrong because it means that people have to keep
double-checking whether the RDFa dialect they are using is the same as
the real thing.

It's like using JScript, ECMAScript, ActionScript and JavaScript.

Or CSS variants on IE, Firefox, Opera and Safari; you see sites full
of those grids of red and green boxes, indicating which browsers
support which CSS features -- I don't believe we want the RDFa
equivalent.


> The most important thing is that exposed instance
> data be as easily interpreted as possible; either via XHTML+RDFa or
> GRDDL/RDFa, for example.

Again, I may have missed a step here, but I believed there to be an
'ODF+RDFa' language, and this is what I am suggesting should include
*all* of RDFa (rather than just some of the language). That way a
'standard' RDFa parser could process and extract the RDFa, and an
author wouldn't need to double-check what RDFa features they have
available to them.


> You point out, and I agree, that subsets create difficulties for developers,
> documentation, and interop. I hope to see RDFa in its full form used in ODF
> and OpenOffice.org. But please if they choose otherwise, let's not sling
> words like 'fork' around so casually. We're amongst friends here, but little
> words like that carry a lot of baggage.

I really hate it when a discussion turns into a meta-discussion. The
meta-discussion rarely ends well, and doesn't usually achieve much
either.

For example, should I now object to your use of the word 'sling' which
implies that I didn't think through my comments? I'm not so sensitive,
and it would certainly be a waste of time...and if I did we'd never
get out of this. But my point is that having discussions about
discussions is pointless.

Anyway, I do think the word 'fork' was fairly used. But my guess is
that the word itself is irrelevant, and that what you are probably
really saying is that we should be grateful that people are using
RDFa, and that we should keep quiet about anything that might prevent
them from using it.

I'm afraid I cannot go along with that.

A lot of people have worked hard on RDFa over the years, because they
fully believe in it as a technology that solves many important
problems. I can assure you that over those years, no-one has done us
any favours, yet RDFa is rapidly acquiring support now, and I believe
the reason for that is that it is solidly engineered.

In other words, RDFa's success will not depend on specific adopters,
but on the solid engineering I just referred to, and clarity. I
believe that makes it perfectly reasonable to ask anyone considering
adopting this technology to take the language in full -- regardless of
how big an organisation they are.

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 Monday, 3 November 2008 13:13:32 UTC