W3C home > Mailing lists > Public > public-rdfa@w3.org > May 2009

Re: Wiki-based vocabulary website idea

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 19 May 2009 09:51:48 -0400
Message-ID: <4A12B974.20402@digitalbazaar.com>
To: Lee Feigenbaum <lee@thefigtrees.net>
CC: RDFa TF list <public-rdf-in-xhtml-tf@w3.org>, Public RDFa <public-rdfa@w3.org>, "Mike Lang Jr." <mikelangjr@revelytix.com>
Lee Feigenbaum wrote:
> Manu Sporny wrote:
>>
>> http://rdfa.info/wiki/wiki-based-vocabulary-website#State_of_the_Art
>>
>> Looking for more feedback...
> 
> [[ CCing Mike Lang Jr, who might have a thought to add here ]]
> 
> The entry on Knoodl states:
> 
> """
> Proprietary mechanisms should not be used to support core web
> infrastructure.
> """

The wording I used on that point was unfortunate and has already been
changed:

http://rdfa.info/wiki/wiki-based-vocabulary-website#State_of_the_Art

Let me elaborate more on what I meant (and I do believe that this
viewpoint is widely held by the standards community):

- When I say "core web infrastructure", I mean things like DNS, HTTP,
HTML, and XML. I place a mechanism for highly-available RDF vocabularies
in the same boat as these other technologies.
- We should not depend on mechanisms whose protocols and methods are
completely undocumented or completely proprietary.
- We should not create a solution where there is only one player in any
solution that we create - there should be a healthy mix of interests
(commercial, academic, non-profit, etc.)

If the creators of Knoodle are willing to open their protocols and allow
interoperability (and mirroring), then great... they can keep their UIs
and back-end system closed. The important thing is that the data lives
on, without creating any sort of disruption, if Knoodle ceases to exist.

> I wonder if this is a widely held view / consensus in the RDFa community?

It seems that the statement I made was taken as "no proprietary
solutions, ever" - which is not what I was trying to express. I was
attempting to make the argument for interoperability - and I didn't see
how we could inter-operate with Knoodle.

> I often talk to people relatively unfamiliar with the Semantic Web
> landscape and praise what I consider a fairly healthy mix of commercial,
> free-but-proprietary, and open-source solutions. 

This is certainly a good thing.

> I'm (personally) a bit
> dismayed that free-but-proprietary (or even, for that matter,
> commercial) solutions would be written off a priori by core advocates of
> the advancement of a Semantic Web vision. 

I don't think things like HTTP, HTML, DNS, and XML should be
proprietary. I do think that systems that use the underlying open
protocols and serialization formats can (and should) be varied.

Also note that the set of issues with Knoodle went beyond just being
proprietary - it was one of the reasons, but not the /only/ reason.

Kingsley Idehen wrote:
> We should be open, and in an unadulterated way. Swapping one mono
> culture for another solves nothing longterm.

I'm certainly not arguing for one mono-culture - all-or-nothing
approaches are rarely good for any ecosystem.

Richard Cyganiak wrote:
> I don't think so. I also think that Manu's comment is inappropriate. I
> agree with the point of view that core web infrastructure should be
> run on open-source software that is as free as possible from
> commercial interests. But a wiki-based vocabulary website is not core
> web infrastructure.

Hopefully you feel that the comment was more appropriate now that there
is some clarification on the comment.

The wiki-based vocabulary website is just part of the set of
requirements - the other is a highly-available RDF vocabulary
infrastructure. I certainly do view this as core web infrastructure
(even if it takes 10-15 years to get there). It would be good for
reasoning agents to have this in the future. Think of it like how we use
DNS... sure, we /could/ each run a complete DNS on our machines, but
rather than do that - most of us depend on an up-stream DNS instead.

Hopefully this clears up the miscommunication regarding the proprietary
solutions comment.

I still hold that we should reject any solution that isn't written in
Python, authored in emacs, formatted with tabs instead of spaces, and
targeted specifically for Debian Linux systems. =P

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: A Collaborative Distribution Model for Music
http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/
Received on Tuesday, 19 May 2009 13:52:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:43 UTC