[uf-new] Dublin Core (was: hAudio FN or Title)

[Brian Suda]

2008/2/4, Ottevanger, Jeremy <JOttevanger at museumoflondon.org.uk>:
> Hi.
>
> Coming out of lurk mode,

--- welcome to the list, and thanks for your thoughts.

> I recognise that The Process wisely advocates that formats should where possible build upon those that exist already, and that a DC microformat might tread on some toes in this respect by creating classes that overlap with existing classes in hCalendar, hCard and so on. I hope this needn't interfere unnecessarily, there's simply too much to be gained from making this suggestion happen.

--- the process also states:
"There must be a problem to be solved (i.e. a real world use case). No
problem, no microformat."

The idea is NOT to make a generic Dublin Core microformats, but to
address a specific problem. People, Places, Events, Music, Books, etc.
If there is something specific, then we can get a use-case and develop
a format from that.

Just making mapping the DC Ontology to class names, doesn´t get us
much. We still need a data format to apply it too.

> There is a ton of content out there that could readily be put into a DC microformat.

--- then we shouldn't look at DC, we should look at that content and
model that, either using existing microformats, or find common
attributes across the examples in the wild, then move through the
process that way. Jumping straight to making a generic OBJECT DC
format is not the best approach.

Microformats are designed to address very specific common problems.
That is not to say that the resulting format can not reuse DC
properties, but to jump straight to a conclusion does not help model
commonly published behaviours.

> To me, now, it makes a lot of sense to pull DC out as a microformat of its own and then think about building more specific applications based on it.

--- this would be backwards to microformats. First we find the
specific real-world commonly published content and give structure to
them.

> ... There are also a large number of!  people out there already that understand DC, that know its role and benefits and the correct way to use the elements (well, sort of), and that would not need to be sold it in the way that they may need to be sold other microformats. Seems sensible to me to tap into that.

--- it certainly does, but it should be in the context of a problem
that needs to be solved, not just picking a format and mapping to it.
Properties in other RDF languages map to DC without using the DC
namespace. Foaf maps properties in it's namespace to Dublin Core.
Microformat can easily do the same thing, there is no prohibition
against this, as long as the meaning is the same. Just because it is
called "fn" or "creator" or something else, doesn´t mean it can't
become Dublin Core properties.

If you or others have a specific idea for a format, then the process
is the best way to move forward. If there is no specific problem that
needs to be solved, then we shouldn't spend the time making a global
solution to non-issues.

Ultimately, microformats are meant to be a simple solution to common
problems. Microformats were not designed to solve every last possible
problem and that is OK. Making a generic DC microformat is attempting
to do this, instead of addressing specific problems.

If the issue can not be solved with existing microformats, then there
are a few options.
1) break it into smaller pieces and see if a format exists?
2) gather data for a new microformat
3) mark-up what you can, and use POSH in other places
4) use something else, like RDFa, eRDF, GRDDL or others.

-brian

-- 
brian suda
http://suda.co.uk