Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add_relationship() does not recognize object PIDs when provided as unicode strings #9

Closed
ghukill opened this issue Jan 9, 2015 · 3 comments

Comments

@ghukill
Copy link
Contributor

ghukill commented Jan 9, 2015

Perhaps this is not a bug, and just how unicode and string objects are treated differently with Eulfedora, but it has caused us various bouts of confusion when creating relationships with add_relationship, and thought it might be worth mentioning.

When using add_relationship(), if you provide unicode objects instead of plain strings, they are not added as rdf:resource to the triple, but instead, as string literals.

For example, object_handle.add_relationship(u'fedora-rels-ext:hasContentModel',u'info:fedora:CM:Collection')

would create the RELS-EXT triple, <hasContentModel xmlns="info:fedora/fedora-system:def/relations-external#">info:fedora/CM:Collection</hasContentModel>

Where, object_handle.add_relationship('fedora-rels-ext:hasContentModel','info:fedora:CM:Collection')

would create, <hasContentModel xmlns="info:fedora/fedora-system:def/relations-external#" rdf:resource="info:fedora/CM:Collection"></hasContentModel>

Now that we know to look out for that, it's relatively easy to manage for, but was not obvious at first.

@rlskoeser
Copy link
Contributor

Looks like a bug. Thanks for pointing it out.

@rlskoeser
Copy link
Contributor

@ghukill just committed a fix in develop. Should go out in the next release.

@ghukill
Copy link
Contributor Author

ghukill commented Jan 13, 2015

That's great! Many thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants