see responses inline
On 28/04/09 23:55, Michael Della Bitta is rumored to have said:
> Hi, I'm wondering if there's an existing body of code or more advanced
> documentation that shows off the add/purgeRelationship and
> getRelationships calls in API-M. I'm a little confused about what
> acceptable values for each of the fields are, the transactionality of
> these calls, when information is written even when an exception is
> thrown, etc.
There's some test coverage of the relationships API which has some code
The relationships API is a set of convenience methods for manipulating
the RELS-EXT datastream. So, acceptable values should map directly to
what's allowed in the RELS-EXT datastream. If an api call throws an
exception, the RELS-EXT datastream should remain untouched.
> In particular, it seems I can create a relationship to an object that
> doesn't exist yet, but I can't purge it. And I'm having difficultly
> creating an entry with a literal value, which seems to be related to
> not knowing when I need to specify a PID as an object identifier or a
> info:fedora/ URI.
The former sounds like a bug. I can look into that--if you have a
stacktrace send it to me or if you don't mind, go ahead and open a bug
on our tracker and post it there. As for the latter, use the short-form
pid, e.g. "demo:123", NOT info:fedora/demo:123.
> Lastly, I'm not clear on how a non-Fedora system predicate should be
> expressed... In the XML, it's kind of clear, I declare a namespace and
> use it, but I can only offer a String to the SOAP call. How should I
> express it here? Via a URI like a namespace?
Just use the full uri, e.g.: "http://example.org/foo#bar".
I don't recall offhand whether you could first create the RELS-EXT
datastream in your object with your own namespace declarations and then
have subsequent addRelationship calls take advantage of that, but my
guess is not. I can look into this while looking at the bug you
> Is the best practice for an organization creating their own
> relationship types to use HTTP URIs with the organization's own
> Internet domain, or something else?
I don't know if it's a best practice, but it seems a common one. Of
course, organization names change and sometime domain names follow, so
even in that case, I don't think that it's terribly important from a
technical standpoint (marketing & branding might say otherwise).