tag delimiter issues

[kkay]

I've just run into a major show-stopper for building a new companion
site to Digital Amherst. We planned a new installation that will
import 50,000+ records currently in an Access DB (newspaper article
citations -- or an index to our local newspapers). This will only be
records, no files/scans.

While the record data is quite simple, just a lot of it, I just
realized the field I wanted to convert to tags has lots of commas that
need to kept. As in, names that are last name first (tag = "Smith,
John") or companies that have complex names (like attorney's firms). I
really want these as tags but need the comma to display -- I also want
the names in a tags list to alphabetize correctly by last name.

This was a minor annoyance in Digital Amherst -- we mostly just
decided to not tag by name. But it is a show-stopper here. I would
highly suggest you revisit commas as the delimiter in the tagging tool
and instead change it to semicolons.

So, for my immediate needs, I am debating trying to change the core so
that the delimiter is a semicolon. Could I simplistically get away
with doing a find/replace across the core files searching for
$delimiter=',' and changing it to a semicolon?? Does that suggest any
major red flags (besides that it is generally a bad idea to muck with
the core)?

Took a look at application/models/Taggable.php, this seems to be the
main place where $delimiter=',' is defined. I'm sure it is other
places as well. I'll try to work on my test Omeka installation and see
how much I screw up things.

Kirstin

[Charles]

Just as a potential idea; is there any way you could intelligently
convert some of your current comma's into their equivalent HTML entity
before importing them? I think the comma html entity is , I
guess this really depends on if you always know it's the first or
second comma you need to keep.

The comma's would still show up in the html output, but I don't think
Omeka would catch them as tags on the import.

I haven't ever done an import like you are, but just wanted to throw
the idea out there if it were possible.

[Jeremy Boggs]

Kristin:

Just to clarify: Do you want to change how the tags are displayed in
your theme? If so, in your theme, you can just pass an argument to any
function that has '$delimiter' to use something else. Here's an
example that uses a pipe instead of a comma:

<?php echo item_tags_as_string('|'); ?>

You can use this in your items/show.php. And, of course, you can use
any other character (or no character at all) as your delimiter. No
need to find/replace in the core at all.

Best,
Jeremy

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

[kkay]

No, the issue is importing. An example, the field to be imported as a
tag is "Doe, John" (last name first). Omeka is going to break that
into two separate tags "Doe" and "John", which is wrong. In admin tag
interface and CSV, by using commas as the separator, I cannot make
more complex phrases. I want to be able to have names as tags and have
them alphabetize correctly by last name.

Also with 50,000 records (though not all names), I cannot normalize
the names to "first name first". Tags are going to be very important
for this installation. I know the comma issue inside single tags has
been brought up before on the omeka.org forum.

Charles' idea of using the html entity was interesting. But I just
tested it in the admin interface and it saves the entity code as plain
text -- so no go.

Back to looking at application/models/Taggable.php for testing this
weekend.

[Wayne Graham]

Kristin,

I think you may just need to tweak the CSV import to allow the rest of
the parameters that fgetcsv has (including the escape sequences). I
believe the default is \, but you should be able to go through with
something like:

"John\, Doe"

To get rid of import issues. I think between this and changing the
default delimiter, you should be able to get around this without too
much refactoring.

HTH,
Wayne

[kkay]

Getting closer, or maybe just creating other problems...

Successful getting the admin add tag interfaces to allow commas within
individual tags (converting the delimiter to ;), which makes me quite
happy. (See http://omekatest.digitalamherst.org/items/tags?sort=alpha
and look at list for "Smith, John"). But when I click on the tag link,
it cannot find the item and serve it up on the browse page. Not sure
how the query string works with tags...

I see that the query is formed like so:
http://omekatest.digitalamherst.org/items/browse?tags=Smith%2C+John
And then rewrites it for display on browse page:
http://omekatest.digitalamherst.org/items/browse/tag/Smith%2C+John

I thought maybe it was %2C becoming part of the query string, but
directly searching "Lovell, John L., 1825-1903" in the creator field
does work.
http://omekatest.digitalamherst.org/items/browse?search=&advanced[0][element_id]=43&advanced[0][type]=contains&advanced[0][terms]=Lovell%2C+John+L.%2C+1825-1903

Any thoughts here??

[Kris Kelly]

Maybe a bit late to this thread, but I gather that changing the tag delimiter would be useful at times.

It would be fairly simple to add another setting to the Settings panel (or perhaps just in the application config file) to specify the delimiter to use for tags.

I will put a ticket up on Trac, though we can't guarantee a timeframe for fixing it.

Are you still having problems with your hacked version?

Kris

[kkay]

Hi Kris,

Thanks for thinking about this issue. I really think being able to use
commas inside tags would be very useful for history websites. Love the
idea of it being in Settings or the config file.

I am still stuck with the URL issue: when I click on my hacked tag, it
cannot find/return any items with that tag on my browse page. I think
it is something with the way the tag URL is rewritten... Any help
appreciated because I just don't know enough about query strings.

What I had documented in previous post:

I see that the query is formed like so:
http://omekatest.digitalamherst.org/items/browse?tags=Smith%2C+John
And then rewrites it for display on browse page:
http://omekatest.digitalamherst.org/items/browse/tag/Smith%2C+John

I thought maybe it was %2C becoming part of the query string, but
directly searching "Lovell, John L., 1825-1903" in the creator field

does return results on browse page.

http://omekatest.digitalamherst.org/items/browse?search=&advanced[0][element_id]=43&advanced[0][type]=contains&advanced[0][terms]=Lovell%2C+John+L.%2C+1825-1903

Thanks,
Kirstin

On Nov 11, 2:56 pm, Kris Kelly <kristopherbke...@gmail.com> wrote:
> Maybe a bit late to this thread, but I gather that changing the tag delimiter would be useful at times.
>
> It would be fairly simple to add another setting to the Settings panel (or perhaps just in the application config file) to specify the delimiter to use for tags.
>
> I will put a ticket up on Trac, though we can't guarantee a timeframe for fixing it.
>
> Are you still having problems with your hacked version?
>
> Kris
>
> On Nov 7, 2010, at 9:41 PM, kkay wrote:
>
> > Getting closer, or maybe just creating other problems...
>
> > Successful getting the admin add tag interfaces to allow commas within
> > individual tags (converting the delimiter to ;), which makes me quite

> > happy. (Seehttp://omekatest.digitalamherst.org/items/tags?sort=alpha

[John Flatness]

The reason for the different behavior you're seeing between searching tags and searching the Creator field is Omeka assumes that the "tag" portion of the query string is comma-delimited as well. Specifying more than one tag returns only those items with all the specified tags. So, the URLs you've posted cause Omeka to look for items with both a tag "Smith" and a tag "John".

If you're still up for a bit of hackery, it's the line

$tags = explode(',', $tags);

in the function filterByTags in application/models/ItemTable.php that's causing you trouble. Replacing it with

$tags = explode(';', $tags);

should fix your problem with comma-containing tags, and still allow you to search for multiple tags using a semicolon.

-John

[kkay]

Thanks. Awesome. That was just what I needed. This will make adding
50,000 records SO much easier. Also, it fits what my users and admins
want when working with tags. Thankfully this hackery was pretty minor.

Again, I love the idea of being able to set the delimiter in the
config file or Settings. Although I suppose this could be done with a
plugin as well?

[Kris Kelly]

I put a ticket up for it:

https://omeka.org/trac/ticket/981