W3C home > Mailing lists > Public > semantic-web@w3.org > January 2010

Re: Alternatives to containers/collections (was Re: Requirements for a possible "RDF 2.0")

From: Dan Brickley <danbri@danbri.org>
Date: Fri, 15 Jan 2010 15:57:58 +0100
Message-ID: <eb19f3361001150657k322196bci2ee23bf4eed5ba44@mail.gmail.com>
To: Sandro Hawke <sandro@w3.org>
Cc: Michael Schneider <schneid@fzi.de>, Jeremy Carroll <jeremy@topquadrant.com>, Semantic Web <semantic-web@w3.org>
(in passing http://www.w3.org/2001/sw/wiki/RDF2Wishlist now has a link
to the old RDF Core Issues list, which Brian and I started before
RDFCore, and which at close of RDFCore WG had a nice section 'stuff
left for other people to worry about in the future....' ---
http://www.w3.org/2000/03/rdf-tracking/#futures )

On Fri, Jan 15, 2010 at 3:31 PM, Sandro Hawke <sandro@w3.org> wrote:

> Perhaps we could run a survey of (self-identified) experts, asking which
> practices they recommend.  If everyone, individually, says "don't use
> feature X", and we make that fact public, that's a pretty good
> un-official deprecation.  It could also, of course, guide a WG in making
> such a change official.
> If we're going to do this, I'd like it to cover more than containers.

The ESW Wiki used to serve something of this role ('E' being an
ambignimic for Europe and/or Extended :)

http://esw.w3.org/topic/RecentChanges shows it is still in daily use
by a few groups, but perhaps isn't getting the levels of curation and
general interest it used to?

> Here are some practices that data providers might follow, which I've
> heard people discourage.  For each of these, we could ask experts (you
> folks) whether these are ever a good idea or should be universally
> discouraged.

I think one of the problems we had with the ESW wiki, was a culture
where people wrote things that were a bit opinionated, in expectation
that wiki-consensus would smooth out any disagreements. So we were
more in the direction of the original c2 wiki (which had a lot of
in-page dialog) than wikipedia, where dialog gets its own page.

I never felt 100% confident pointing people at ESW as the contents
were just a bit too chaotic and unpredictable. But nevertheless I
suspect a wiki approach could be the right way forward here (given
limited resources and time). It would need culture/expectations of
documenting pros/cons of the issues. Not always easy for people with
strong technical opinions, especially when the wiki isn't active
enough that the threat of having one's opinionated text deleted isn't
as real as it would be on -say- wikipedia.

>  I expect people providing RDF data could benefit a lot
> from know which of these practices are considered bad by 100%, 50%, or
> 0% of the experts.  (Some of them would need a more full explanation
> than this, I think.)
>     - using alt/bag/seq in your data
>     - using parsetype collection or rdf:first/rest/nil in your data
>     - using OWL cardinality to close off your instance data (bldg has 17 rms)
>     - using rdf's reification vocabulary
>     - using blank nodes
>     - using plain literals (no datatype, no language tag)
>     - using type xs:string
>     - using language-tagged strings
>     - having the order of triples affect the meaning of data
>     - having the order of triples affect performance
>     - having your data imply something new if triples are omitted
>     - using IRIs for which there is no dereference mechanism (eg tag URIs)
>     - using http IRIs which are 404 or otherwise are not linking data
>     - leaving out rdfs:label information for some terms
>     -   ...

Good questions!

> Any more ideas?  Should we make it about both bad and best practices, or
> just bad/not-bad like I've done?  In some cases, I put in the negation
> of a best practice, as a bad practice, but maybe that's too confusing.

Sounds like a frontpage and a set of wiki pages to me. Something to
try in http://www.w3.org/2001/sw/wiki/Main_Page ?


Received on Friday, 15 January 2010 14:58:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:05 UTC