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

[Ottevanger, Jeremy]

Brian, thank you for your response. Martin, too - I'll bundle my reply to you into this, hope that's OK. I appreciate it that people take my confused ramblings seriously enough to take the time to give a considered response! 

The reason I hopped into this discussion is that I do have a specific purpose in mind, one that I'd spent some time trying to develop but had let stagnate due to (a) lack of time and (b) confusion in the face of the plethora of options other than microformats (which you list below). Ironically it was the specific nature of the problem that I wanted to do tackle that seemed to be the problem when I first talked about it on this list and the discussion list, last May/June (the scenario: identifying objects in museums and galleries on the page, attaching core metadata to them). I now agree - what I wanted to do was too domain-specific. 

The most useful uFs, it seems to me, are broad in applicability and narrow in scope (e.g. dates, location data). I can undestand that the idea of DC as a microformat trips people up with because it is not narrow in scope (i.e. dates, agents, locations, descriptions around a "thing" are all in there), but it's certainly broad in its applicability. What I wanted to do was pretty narrow in both respects. I did, as you suggest, break it down and use other uFs where possible, but the need for a wrapper for the object as a whole still existed. It strikes me that a DC microformat would be cool because it could offer a broadly useful way to wrap up information about an object. The fact that it would NOT be narrow in its applicability would be a good thing, I think. No current uF, as far as I know, provides a wrapper I can use for a generic object. Why do we want to be so specific that a book, an audio recording etc. all have to have different containers? That's very useful in certain contexts, and clearly the case for microformats for these has been made and won and I wouldn't refute their utility. But if I want to put some other kind of object up there then these wrappers are no use. I just want to be able to identify a thing on a page, and I can't right now - what's out there is TOO specific. That specificity is probably what made it easy to come up with use cases for them, but it's also why they fail to work for loads of stuff.

With a "thing" uF, built around DC, you could use the same format to represent a document in an archive, an axe head in a museum, a book in a library, a photo or a video online. And I guess this may be where the problems mainly lie: this means that such a format would tread onto the ground currently covered by other microformats (such cross-over isn't exactly unprecedented but it's not ideal, of course), and I appreciate your point, too, that DC lies behind other uFs (or they can be mapped to it). But for me, in an institution that holds data about a wide variety of objects, I would rather have a single format to output (having done all the semantic mapping internally), whether the object I am describing is an audio recording, a book, an axe head or a digital artwork. A domain-specific (I mean, museum and gallery) GRDDL profile or some extra bit of POSH might also be useful for some of the extra bits of data I'd quite like to enable, but overall I would much rather NOT use my earlier "museum object" microformat to hold this metadata - I'd prefer to use (and possibly extend) a widely applicable DC uF in the knowledge that people outside museums will be using something similar. 

I understand the need for use cases, so here are some:

- a user collects (records of) documents held in The National Archives for her history project. Her user agent gathers titles, source, thumbnails, authors, dates and home URLs for these. She can pool them with other material she's found and feed them into Zotero.
- a bronze age specialist searches several museum websites, "collecting" a set of artefacts. The add-in in his browser finds objects from the relevant period and geographic area, of the type "sword". Through the add-in he feeds these objects into his collection, a web-based, taggable "delicious" for museum things. His peers in the "bronze-age weaponry" user group see what he has found and get to annotate it.
- a search engine spiders museum, library and archive websites across the UK/Europe/world and gathers data on items in their collections, building a cross-collections search independent that points to each source site

Perhaps these aren't good use-cases, I'm an amateur, and these are very museum-focused. I hope they at least show the itch I'm trying to scratch: letting users grab and play with data about our collections.

Yes, like any other microformat you could choose to try eRDF, GRDDL etc. to achieve this. But I still wonder, why on earth should there NOT be a generic microformat out there to capture outline information about all sorts of "things" that fall through the cracks left by other, very specific "thing-related" uFs. Frankly without one there's far less in it for me - I have only so much use for events and locations in the abstract, with no way to wrap them up and attach them to things; museums and galleries tend to deal in material culture (as do shops, though I guess they're not too hot on DC) and if I can't use microformats to capture data about this then microformats start to lose their appeal.

OK, I know you had more challenges for me, but I know my limits! I really wanted to stick my hand up and vote for the idea that was being batted about re DC, but I'm sticking to the shallow end. And talking about it at excessive length...apologies!

All the best,

Jeremy


-----Original Message-----
From: microformats-new-bounces at microformats.org [mailto:microformats-new-bounces at microformats.org] On Behalf Of Brian Suda
Sent: 04 February 2008 12:00
To: For discussion of new microformats.
Subject: Re: [uf-new] Dublin Core (was: hAudio FN or Title)

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

_______________________________________________
microformats-new mailing list
microformats-new at microformats.org
http://microformats.org/mailman/listinfo/microformats-new