References and "@"

[Benjamin Kalish]

Hey folks,

Can someone explain to me the motivation for prefixing all references with the "@" sign? All the examples of its use in the specification are as the value of a "ref" attribute, in which case, presumably, the string would have to be a reference.  Are there cases where an attribute could take either a string or a reference and a program must look for the "@" to distinguish to the two cases? Is the "@" sign redundant? As it stands, I don't see why we can't use just a local id for local references and "@" plus a full id for global references instead of using "@" plus a local id for local references and "@@" plus a full id for global references.

Many thanks,

Benjamin M. Kalish

[Jack Alves]

I am not a fan of the @ for reference either. I see that it is an irON attribute which is inherited by BibJSON. Seems like @ and @@ are unnecessary because for a global ID the full URI is required. If an app wanted to know if the ID is local or global it could check for a domain in the URI. If there is no domain or the domain is the same as the host then the ID is local.

(see attribute reference just above  Record Attribute Structure section  in BibJSON spec)

"A ref attribute refers to the local ID if the first character of the id is "@". A ref attribute refers to a global ID (URI) if the first two characters of the id is "@@". If the ref attribute refer to the global ID of an record, this record can be local, or remote (this means that the record referred by the ref attribute is defined in another dataset)."

To unsubscribe from this group, send email to bibjson+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[Benjamin Kalish]

Perhaps Frederick or some else involved in irON can offer some insight into this. I haven't explored the connections between BibJSON and irON at all and have very little sense of how the two work together or what the motivation for the irON conventions might be.

Ignoring the possible implications of the irOn connection, here are my thoughts:

The BibJSON spec currently specifies that the full id of each record be a URI, which is not necessarily a URL. URIs are not required to have a domain, so we can't use the above test exactly as proposed.

We may be able to support general URIs and still dispose of "@" signs. What if, instead of checking for the domain in the URI, our test checked for the scheme part of the URI? If it is present we are looking at a global id, if it is absent we are looking at a local id. This wouldn't be a perfect solution as some "relative" URIs contain colons and appear to have a scheme even when this is not the author's intent, but this is an existing problem with many similar systems and can easily be avoided by not using the colon in the path part of URIs. This would certainly result in references that look more familiar, and it might be nice, from a practical perspective, if we could use relative URIs, with all their associated conventions, where the URI scheme allows them.

If, however, we are going to support URIs that aren't URLs and we want to be absolutely free of ambiguity then it may still be necessary to tag the difference between a global and a local reference in some way.

Is it important that we support URIs that aren't URLs? I'm not sure. We already require that the full id of a record be constructible by concatenating the dataset id and the local id, and the suggest a hierarchical structure that is definitely URL-like. But then, URLs are meant to give the location of a resource, even if they aren't always used that way, and some folks have spoken out about the importance of supporting IDs which do not necessarily imply that a resource can be retrieved.

Is it important that we are absolutely free of ambiguity. I don't like ambiguity, but the ambiguity presented by using relative URLs is low, already exists in other systems, and there authors can almost always find work arounds to make sure there references are interpreted correctly. I still don't like ambiguity however.

I'd love to hear what folks have to say about this. I am, by the way, also still interested any proposals as to how the method of resolving ids might be specified within a BibJSON dataset. I'm currently working on some code to resolve BibJSON references, but it only works when the id is a URL with the http, ftp, or file scheme. I'm treating all other ids as unresolvable. This isn't a problem for my own datasets, which always use ids with the file or http scheme, but I'd like to know what those folks who might use other schemes have in mind.

All the best,

- Ben