More Re-Usable Omeka Data

[Trevor Muñoz]

Hi,

Forgive me if this message repeats an earlier topic—a few quick searches in this forum didn't immediately surface anything that seemed exactly on point.

A good number of site built on omeka.net sites have come across my various feeds recently (hooray) and eventually I got curious about some of the specifics related to how the item-level metadata is presented. I was a little disappointed to see that (in the sample of sites I looked at), only human-readable representations of Omeka's nice Dublin Core metadata (i.e., plain HTML) are published. Without machine-readable representations, this metadata is not as re-usable as it could be. Omeka is to be applauded for pushing people to create structured data using standards (!) for their digital projects. It would be wonderful to go one step further and make this metadata more widely consumable and re-usable.

What about adding RDFa support to Omeka's metadata display functions? (Any of the flavors of embedded markup would do but RDFa seems like the low-hanging fruit since Omeka is already capturing/creating Dublin Core. The addition of @vocab and @property attributes would do the trick.)

If I'm reading the codebase correctly (caveat: I don't really ever program in PHP), this change could be effected with some "small" changes to /application/views/scripts/common/record-metadata.php. So, the resulting presentation of metadata would be something more like:

<h2 vocab="http://purl.org/dc/terms/">Dublin Core</h2>

<h3>Title</h3><p property="title">This is the item title</p>

Or, something similar. (I would submit this as a pull request but I'm not totally confident I understand everything going on in that php file to make the changes correctly.)

This would add a very basic layer of machine-readable data to Omeka pages and would greatly improve the reusability of data that people create in their Omeka sites. I suppose this could be left to individual themes or customizations but making this a core change would be a great contribution that Omeka could make to best practices in digital projects. A kind of "sane default" for data.

Thanks for considering and apologies again if this is going over ground that has been well-trodden.

Best,

Trevor

[Patrick Murray-John]

Funny you should mention that.

Some upcoming projects of our call for greatly improving data-interoperability, and RDF/RDFa are explicitly mentioned. These are part of future plans, building off of Omeka 2.x, so I'm not sure when they might trickle into .net.

Right now, I imagine a beginning approach might be to do that with a plugin, using the filters available for displaying metadata.

So, it is on our radar. Glad to hear there is interest out there!

Thanks,
Patrick

On 03/18/2013 10:15 AM, Trevor Mu�oz wrote:

Hi,

Forgive me if this message repeats an earlier topic�a few quick searches in this forum didn't immediately surface anything that seemed exactly on point.

A good number of site built on omeka.net sites have come across my various feeds recently (hooray) and eventually I got curious about some of the specifics related to how the item-level metadata is presented. I was a little disappointed to see that (in the sample of sites I looked at), only human-readable representations of Omeka's nice Dublin Core metadata (i.e., plain HTML) are published. Without machine-readable representations, this metadata is not as re-usable as it could be. Omeka is to be applauded for pushing people to create structured data using standards (!) for their digital projects. It would be wonderful to go one step further and make this metadata more widely consumable and re-usable.

What about adding RDFa support to Omeka's metadata display functions? (Any of the flavors of embedded markup would do but RDFa seems like the low-hanging fruit since Omeka is already capturing/creating Dublin Core. The addition of @vocab and @property attributes would do the trick.)

If I'm reading the codebase correctly (caveat: I don't really ever program in PHP), this change could be effected with some "small" changes to�/application/views/scripts/common/record-metadata.php. So, the resulting presentation of metadata would be something more like:

<h2 vocab="http://purl.org/dc/terms/">Dublin Core</h2>

<h3>Title</h3><p property="title">This is the item title</p>

Or, something similar. (I would submit this as a pull request but I'm not totally confident I understand everything going on in that php file to make the changes correctly.)

This would add a very basic layer of machine-readable data to Omeka pages and would greatly improve the reusability of data that people create in their Omeka sites. I suppose this could be left to individual themes or customizations but making this a core change would be a great contribution that Omeka could make to best practices in digital projects. A kind of "sane default" for data.

Thanks for considering and apologies again if this is going over ground that has been well-trodden.

Best,

Trevor

--
You received this message because you are subscribed to the Google Groups "Omeka Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omeka-dev+...@googlegroups.com.
To post to this group, send email to omek...@googlegroups.com.
Visit this group at http://groups.google.com/group/omeka-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
�
�

[Jeremy Boggs]

On Mar 18, 2013, at 10:53 AM, Patrick Murray-John <patric...@gmail.com> wrote:

> Right now, I imagine a beginning approach might be to do that with a plugin, using the filters available for displaying metadata.

Was just looking into this, Patrick. What filters are available that would allow you to do this?

I was going to suggest creating a plugin that would offer a replacement for the record-metadata.php template, but there isn't a way to filter the `partial` option in Omeka_View_Helper_AllElementTexts. Looks like the only thing you can filter in that helper is the list of elements to display.

Jeremy

[John Flatness]

Though it's not particularly apparent from the public side at the
moment, there is actually an RDF-XML version of the Dublin Core metadata
for each item that's exposed.

You can get to that XML output by appending ?output=dcmes-xml to the
item's URL. There's also the omeka-xml output, which includes data
beyond Dublin Core, but in an Omeka-specific schema.

-John

>> changes to /application/views/scripts/common/record-metadata.php
>> <https://github.com/omeka/Omeka/blob/master/application/views/scripts/common/record-metadata.php>.

[Patrick Murray-John]

Jeremy,

Was thinking of the Element Display filter.
http://omeka.readthedocs.org/en/latest/Reference/filters/Element_Display_Filter.html

That'd require adding the filter individually for each element, though.
It might be nice to have one filter that'd apply to all elements by
default, and put the work of separating out behavior in the plugin's filter

Not entirely sure what the best approach would be at this stage, though.

Patrick

[Jeremy Boggs]

On Mar 18, 2013, at 11:17 AM, Patrick Murray-John <patric...@gmail.com> wrote:

> Was thinking of the Element Display filter. http://omeka.readthedocs.org/en/latest/Reference/filters/Element_Display_Filter.html
>
> That'd require adding the filter individually for each element, though.

That also only returns the text of the each field, and not the HTML wrapped around it. Suppose you could wrap additional HTML around the text value. This would not let you add the `vocal` attribute to the element set's header, though.

> It might be nice to have one filter that'd apply to all elements by default, and put the work of separating out behavior in the plugin's filter

Being able to filter the partial using in AllElementTexts would do the job quite well. Would be a pretty handy filter to have, too.

> Not entirely sure what the best approach would be at this stage, though.

I think it'd be interesting to see a view partial similar to record-metadata that could be passed to all_element_texts() in a theme that would accomplish this. That could be shared, perhaps in a gist or something. Trevor, think you could do that? Wouldn't need to be a pull request, just create a file anyone could download and add to a local theme to test out. That would at least give theme developers some guidance on how to implement this kind of feature.

Jeremy

[Patrick Murray-John]

On 03/18/2013 12:17 PM, Jeremy Boggs wrote:
> On Mar 18, 2013, at 11:17 AM, Patrick Murray-John <patric...@gmail.com> wrote:
>
>> Was thinking of the Element Display filter. http://omeka.readthedocs.org/en/latest/Reference/filters/Element_Display_Filter.html
>>
>> That'd require adding the filter individually for each element, though.
> That also only returns the text of the each field, and not the HTML wrapped around it. Suppose you could wrap additional HTML around the text value. This would not let you add the `vocal` attribute to the element set's header, though.

Blurg. yeah. How, indeed, to get the attributes in the right places. I'm
not so worried about the vocab attribute, though. Easy enough to use
`dct:creator` etc.

>
>> It might be nice to have one filter that'd apply to all elements by default, and put the work of separating out behavior in the plugin's filter
> Being able to filter the partial using in AllElementTexts would do the job quite well. Would be a pretty handy filter to have, too.

Yeah. Only hesitation is about themes that don't use all_element_texts,
and instead show bits of metadata individually. Don't think we do this,
but it comes up in forums here and there.

[Trevor Muñoz]

I think it'd be interesting to see a view partial similar to record-metadata that could be passed to all_element_texts() in a theme that would accomplish this. That could be shared, perhaps in a gist or something. Trevor, think you could do that? Wouldn't need to be a pull request, just create a file anyone could download and add to a local theme to test out. That would at least give theme developers some guidance on how to implement this kind of feature.

Jeremy— I'm not sure I followed all of the discussion between you and Patrick. I would be happy to provide an example of something via gist to help theme developers implement embedded metadata. Not quite sure what the view partial example should look like in this context. Sorry to be dense.

Trevor

[Patrick Murray-John]

'Course, I suppose there's little we can do for themes that avoid
all_element_texts

On 03/18/2013 12:17 PM, Jeremy Boggs wrote:

[Sara Amato]

Looks like there might be a problem on the omega.org site, unless Egypt SEO is something new with Omeka ;^)

[Patrick Murray-John]

Ack! thanks! let the reversions begin!

On 03/18/2013 01:05 PM, Sara Amato wrote:

Looks like there might be a problem on the omega.org site, unless Egypt SEO is something new with Omeka ;^)

--

[Trevor Muñoz]

Nifty. Glad to know about this. Still think it would be great to put the structured form of the metadata directly in the main HTML display as well.

Trevor

[Trevor Muñoz]

Also, since there is already an RDF/XML version of data being created it would be great to add a simple link relation in the header of these pages. For example:

<link rel="alternate" type="application/rdf+xml" href="/items/show/111?output=dcmes-xml" />

A post by Ed Summers on doing something like this for EAD has more details: http://inkdroid.org/journal/2012/10/24/level-0-linked-archival-data/

Thanks again.

[Jeremy Boggs]

On Mar 18, 2013, at 12:54 PM, Trevor Muñoz <trevor...@gmail.com> wrote:

I think it'd be interesting to see a view partial similar to record-metadata that could be passed to all_element_texts() in a theme that would accomplish this. That could be shared, perhaps in a gist or something. Trevor, think you could do that? Wouldn't need to be a pull request, just create a file anyone could download and add to a local theme to test out. That would at least give theme developers some guidance on how to implement this kind of feature.

Jeremy— I'm not sure I followed all of the discussion between you and Patrick. I would be happy to provide an example of something via gist to help theme developers implement embedded metadata. Not quite sure what the view partial example should look like in this context. Sorry to be dense.

I'm suggesting that, for any of the changes you wanted to make to the record-metadata.php file, go ahead and do that, but rename the file to something like `record-metadata-rdfa.php` and share that file in a gist or some other way. The partial itself should probably look pretty much like the current record-metadata.php partial, with your additions that include RDFa data.

You can rename that partial, keep it in your public theme's `common` directory, make whatever changes you want, then pass that partial as an option to the `all_element_texts()` helper in items/show.php:

<?php echo all_element_texts('item', array('partial' => 'common/record-metadata-rdfa.php')); ?>

Jeremy