Re: Schema.org in RDF ...

>
>
> Again, this strikes me as speaking from very little experience. I
> spend a good deal of my time collaboratively developing ontologies and
> working with users of them. I've yet to encounter a person who didn't
> understand the difference between a book about Obama and Obama.
>

My experience is with an extensible system which powers about 2% of the Web,
which has over 10,000 contributed modules and 1,000 developers working on
the core platform—Drupal. I have been one of the two primary people
developing and educating users about the use of Linked Data technology in
Drupal 7. This may be different than your experience, but it certainly isn't
negligible experience when talking about the successful adoption of these
technologies.


> It depends on the manner in which the system is made extensible.
> Architecture and good design matters. However, It is this attitude
> that has led, in part, to the prulgation of schema.org as a closed
> architecture.
>

The system is extensible via the hook system, which basically follows the
aspect oriented paradigm. It also uses what can be considered a Presentation
Abstraction Control architecture (also called Hierarchical MVC), where the
different agents at different levels of the hierarchy can come from
different modules designed by different developers. This extensibility means
developers with a very wide range of knowledge and experience can contribute
parts of the functionality. I think this is a good thing, as do many others
who attribute Drupal's success to these architectural features.

Because different parts of the EAV relationship are extensible and can be
developed by different developers in Drupal, it requires that all parties
understand the distinction between info resource and thing resource and how
to put that in practice. This means teaching them to* sometimes* use hash
URIs when content is entered (which overloads the hash URI with different
meanings, as it is already used for another purpose in HTML) or to use 303's
with content negotiation (which even some vocabulary publishers deeply
embedded in the SemWeb world don't seem to understand how to do).

Good design does matter, but we have to define what we are optimizing for
when we say good design:

   - If you are optimizing for correctness, then good design means making
   everyone understand and use this new distinction and changing the workflow.
   - If you are optimizing for large scale participation, then good design
   means you work with the workflows that users are already familiar with and
   just supplement those workflows with SemWeb technology where the technology
   has the chance of making something easier.


I do believe that if someone steps back and thinks about it, making the
distinction between a Web page about a person and the person themselves does
make sense. But most people aren't stepping back and thinking about it, they
are doing... and we aren't there in the room with them to tell them to take
a step back and think. We can wag fingers all we want at these people, but
really the most successful Web designs Don't Make Me Think.

I think we also have to understand what is the best solution for now—when
people don't yet understand these technologies and we need adoption—and what
is the best solution for 10 years from now—when, if we have
been successful at getting the tech adopted, people will understand the
fundamentals of this technology and can be taken a step further.

Best,
Lin