Skip to content

Abuse of describedby relation in link header #197

Closed
cygri opened this Issue Nov 13, 2012 · 46 comments

7 participants

@cygri
cygri commented Nov 13, 2012

Section 7.4 Referencing Contexts from JSON Documents says that an HTTP header with relation describedby can be used to associate an external context with a JSON document.

I'm concerned that this is an abuse of the describedby header.

The semantics of describedby relation type, as defined by POWDER and registered with IANA, is to link to a POWDER document that describes the subject resource, in other words, provides metadata about it.

Thus, if there's a describedby link from a JSON document to a JSON-LD document, the correct interpretation to me seems to be that the latter is a POWDER document serialized in JSON-LD that provides metadata about the JSON document. Nothing in the relationship type registration or in the POWDER spec suggests that it can be interpreted as an association of a JSON-LD context with the JSON document that allows processing the JSON document as JSON-LD.

It seems to me that JSON-LD should define its own relationship type with the precise semantics as described in Section 7.4, or else drop the mechanism described in 7.4.

@tidoust
tidoust commented Nov 13, 2012

While the section in POWDER seems to imply that describedBy is for POWDER, the actual Link Relationship submitted to IANA defined in Appendix D: describedby Link Relationship is actually explicit that there are no constraints on formats:

The relationship A 'describedby' B asserts that resource B provides a description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource.
http://www.w3.org/TR/powder-dr/#appD

That seems in line with the use made in JSON-LD.

At a minimum, JSON-LD should reference the definition of describedBy in POWDER.

@lanthaler
JSON-LD Public Repositories member
@cygri
cygri commented Nov 14, 2012

The abuse stems not from the fast that the target isn't a POWDER resource. The abuse stems from the fact that the target isn't a description in JSON-LD of the source.

A @context is not a description of a JSON document. It is a processing instruction that says how a JSON document can be processed as JSON-LD.

An appropriate use of rel="describedy" type="application/json-ld" would be a real JSON-LD document that describes the source.

The current design precludes the use of actual JSON-LD documents with rel="describedby".

@niklasl
JSON-LD Public Repositories member
niklasl commented Nov 14, 2012

I agree, the semantics seem quite different. What's needed is something like rel=profile or rel=transformation (see GRDDL: http://www.w3.org/2003/g/data-view). None of those are registered IANA relations though, so we need a full URI. Either one of those, or for a new "context" property, unless someone finds anything more appropriate (I'm not particularly fond of the microformats list of existing rel values, but we might shop around there as well I presume.)

(In a convergent world, where JSON-LD contexts could be used with microdata, what would be the appropriate link relation to such a context?)

@lanthaler
JSON-LD Public Repositories member

Sorry, I still disagree. IANA (which is the authoritative source here) defines the semantics of describedby as follows:

Refers to a resource providing information about the link's context.

Maybe I'm missing something, but aren't we using it for exactly that reason? We provide information about a JSON document's context which allows a JSON-LD processor to interpret it as Linked Data.

@philarcher

Thanks to François for alerting me to this thread.

On the semantics of describedby, I can ally all fears. The IANA definition is correct - if A is describedby B there is no inference that B is a POWDER doc. The error in the Recommendation is recorded at http://www.w3.org/2007/powder/powder-errata#describedby (an error that has caused me more pain than I can recount, not least trying to work out how the heck I can update the docs within W3C policy on editing stuff once it's in /TR space but that's a side issue).

However, from there on it gets a little less clear.

I have sympathy with Richard's view that @context is a processing document - a set of instructions cf. a description. However, I also have sympathy with the view that a document that tells me how to interpret another one is, in at least some sense, a description of it. A translation of this text into French would in at least some sense describe the content to a monoglot French speaker. A glossary can be seen as providing descriptions of terms - OK, we'd say definitions of terms, not descriptions but it's close.

Yes, transform is probably a better word than describedby in this context, but I go back to the definition:

"The relationship A 'describedby' B asserts that resource B provides a description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource."

The constraint comes from the MIME type of A and B. The spec could make explicit that:

If A is application/json and B is application/json-ld then

A rel="describedby" B implies that B is a description of how to process A into JSON-LD

HTH

Phil.

@cygri
cygri commented Nov 14, 2012

@lanthaler I doubt that the word “context” as used in the describedby registration has anything to do with the thing called “context” in JSON-LD.

@philarcher Your proposal precludes the use of JSON-LD as a format to actually describe JSON documents.

@tidoust
tidoust commented Nov 14, 2012

OK, I get it this time and agree: we'll want to use JSON-LD as a description format to make statements that describe other JSON or JSON-LD documents and we'd need to use the describedBy relation to do that.

I also agree with Niklas that GRDDL's transformation matches our use case:
http://www.w3.org/TR/grddl/#grddlvocab

@lanthaler
JSON-LD Public Repositories member
@cygri
cygri commented Nov 14, 2012

@lanthaler

  1. Because “context”, according to the dictionary, means “surrounding circumstances”, “interrelated conditions”. That is consistent with how the IANA registration uses the term AFAICT, and it's not consistent with how JSON-LD uses it. Information about how to interpret something else isn't “contextual information” about that thing.

  2. I talked about using a JSON-LD document to describe a JSON document. That's not a different representation of the same data. Do I need to explain to you the difference between a thing and a description of the thing?

@lanthaler
JSON-LD Public Repositories member
  1. Because “context”, according to the dictionary, means “surrounding circumstances”, “interrelated conditions”. That is consistent with how the IANA registration uses the term AFAICT, and it's not consistent with how JSON-LD uses it. Information about how to interpret something else isn't “contextual information” about that thing.

Well, in my opinion it is:

  • Context: "the parts of a written or spoken statement that precede or follow a specific word or passage, usually influencing its meaning or effect" dictionary.com

  • "context, those parts of a text preceding and following any particular passage, giving it a meaning fuller or more identifiable than if it were read in isolation" answers.com

  • Context: "the parts of a discourse that surround a word or passage and can throw light on its meaning" Merriam Webbster

  • Context: "The part of a text or statement that surrounds a particular word or passage and determines its meaning." The free dictionary

2.I talked about using a JSON-LD document to describe a JSON document. That's not a different representation of the same data. Do I need to explain to you the difference between a thing and a description of the thing?

No. Please don't let us go down that path..

@cygri
cygri commented Nov 15, 2012

It's doubtful that this is the sense that the IANA registration intends. Also, how does any of those definitions apply to JSON-LD?

@philarcher

This really isn't my argument but fwiw I agree that GRDDL's @rel type of transformation is a better fit than describedby. Getting it into the HTTP Link Registry is not hard (http://tools.ietf.org/html/rfc5988#section-6.2) especially as transformation is defined in a W3C Rec already.

However... that raises a number of issues, firstly and most easily, although the GRDDL Rec does define @rel transformation, it doesn't of course magically edit the XHTML spec (http://www.w3.org/TR/xhtml-modularization/abstraction.html#s_common_types) nor does it make it into HTML5 http://dev.w3.org/html5/spec-preview/links.html#linkTypes but if you include it in the JSON-LD spec and get Mark Nottingham to include it in the registry, then the job might be done.

But there's more... you then run into exactly the problem that kicked off this discussion. The range of transformation is Transformation, defined as "an InformationResource that specifies a transformation from a set of XML documents to RDF graphs..." Which basically gives you a domain of XML and a range of RDF. The reason describedby gets traction (despite the erratum) is that it does no such thing. describedby was actually defined over a very pleasant lunch I had with MNott at Cambridge Circus in London. His key message was to make sure that the relationship did not have any domain and range and to let the MIME types do their job. That's why the (proper) definition of describedby says that given the assertion: A describedby B, the only inference is that B describes A. It tells you nothing about what format A and B are in.

Therefore, using GRDDL's transformation property could be problematic and I come back to Richard's original thought that actually, a new term may need to be minted. Thrashing around my native speaker skull for an alternative I wonder whether either 'augment' or 'processable' might do what is needed? So:

A augment B

would say that B can augment (i.e. add to/enrich) A

alternatively

A processable B

says only that B can be used to process A.

The problem with augment is that it might be seen as pejorative (i.e. people who think JSON is all you ever need for everything will balk at the idea that JSON-LD is in some way augmented). Although I think it's a better term than processable since why would you ever want to link to anything that wasn't? ;-)

The problem ever here is that actually there are 3 elements: the input file A (JSON), the context file B (also JSON) and the output JSON-LD... and linked relationships don't really cover that. Even so, I think the fact that B augments A is what we're looking at here and since the output is also JSON, it should be OK?? Convention and usage are powerful things...

@lanthaler
JSON-LD Public Repositories member

Sorry but I don't think this discussion here leads to anything. I therefore wrote a mail to IETF's link-relations mailing list to ask for their opinion. In the end they are the maintainers of the registry and consequently the responsible authority.

@cygri
cygri commented Nov 15, 2012

@lanthaler Okay I'll spell this out once more for you.

Let's say there's a nice JSON file at http://alice.example.com/addresses.json. It's a dump from Alice's address book app in a JSON format specific to that app.

Now, Alice also publishes some RDF metadata that describes the stuff on her website. That's published in Turtle at http://alice.example.com/meta.ttl and contains this bit:

<addresses.json> a foaf:Document;
    dc:title "My address book in FooAddress dump format";
    dc:modified "2012-11-15T12:34:56"^^xsd:dateTime.

Now, Alice would like that metadata to be discoverable from the JSON file itself. That's what the Link HTTP header is for, right? So she configures the server to add that header. Looking for an appropriate link relationship, she finds describedby which seems to be perfectly appropriate:

Link: <meta.ttl>; rel="describedby" type="text/turtle";

Great! Now, any processor that understands the describedby relationship and Turtle can find the metadata!

A bit later, Alice hears about this new thing called JSON-LD. She looks at it and decides that it's much better than Turtle. She does away with meta.ttl and publishes meta.jsonld instead, with appropriate media type and all. It looks something like this:

{
    "@context": {
        "foaf":"http://xmlns.com/foaf/0.1/",
        "dc":"http://purl.org/dc/terms/",
        "xsd":"http://www.w3.org/2001/XMLSchema#",
        "dc:modified":{"@type":"xsd:dateTime"}
    },
    "@id": "addresses.json",
    "@type": "foaf:Document",
    "dc:title": "My address book in FooAddress dump format",
    "dc:modified": "2012-11-15T12:34:56"
}

Of course she also changes the link header:

Link: <meta.jsonld>; rel="describedby" type="application/ld+json";

Great! Now, any processor that understands the describedby relationship and JSON-LD can find the metadata!

Or can it? No, because according to the JSON-LD spec, a JSON-LD processor has to interpret this header as copying the @context from Alice's metadata document into the address book app's JSON dump! So, instead of having metadata associated with the JSON dump as Alice intended, she now has a JSON-LD processor that produces garbage by interpreting her address book dump as JSON-LD with a context not intended for it.

The problem is caused by imposing a definition of the describedby header that is much narrower than what's written in the IANA registration. Thereby preventing reasonable uses of describedby that lie within the scope of the IANA registration, but outside of the narrow interpretation demanded by the JSON-LD draft.

The fix is one of those:

  • Use a different rel value
  • Use different media types for JSON-LD documents and stand-alone JSON-LD contexts
  • Use not @context to signify the JSON-LD context to be used, but a different key (@ThisIsAnExternallyReferenceableContext), and state that if it is absent, the usual interpretation of describedby applies
  • Drop section 7.4

Update: Edited the conclusion paragraph and list of fixes

@lanthaler
JSON-LD Public Repositories member

Richard, I understand your point but in the end they are two different use cases. IMO the describedby link relation is completely appropriate for both.

We say (perhaps not clearly enough) that if you link from a JSON to a JSON-LD document via a describedby link relation, a JSON-LD processor can take the @context of the referenced JSON-LD document to interpret that JSON document.

I agree that our definition is much narrower than IANA's definition but that doesn't automatically invalidate it. IANA's definition is independent of specific media types and software products. We just specifiy how it should be used by a JSON-LD processor for a JSON document linking to a JSON-LD document.

What rel value would you suggest instead?

@cygri
cygri commented Nov 15, 2012

They are indeed two different use cases. The problem is that the draft as written prevents a legitimate use case. As written, describedby cannot be used with JSON-LD for the purpose that describedby and JSON-LD were made for—associating metadata with a resource, and expressing data.

I have not researched other rel values, so don't have an opinion on what else to use.

@lanthaler
JSON-LD Public Repositories member

It cannot be used with a JSON-LD processor for that purpose as a JSON-LD processor would interpret it that way. Maybe all we need to do is to make it clearer that this is how a JSON-LD processor uses such a link!?

@cygri
cygri commented Nov 15, 2012

No, because it permanently precludes a legitimate use case with no way of fixing it later once the current draft design gets deployed.

We're 18 comments in, and you still haven't stated a single reason that justifies the questionable design choice, except insisting that no problem exists.

I think I've done an honest effort here. I'll raise this again as a Last Call comment, and am unlikely to stand aside for a no-change proposal.

In the meantime, consider the easiest way of resolving this:

PROPOSAL: Do not include a HTTP header based context discovery mechanism in JSON-LD 1.0

@philarcher

That can't be right, Richard. That is, your proposal not to include HTTP Link because the WG can't agree on a @rel type.

Separate train of thought but we (the W3C Team) are looking at possible support for a new WG to look at Data on the Web. JSON and JSON-LD should, I hope, be very relevant. A hot topic though is data discovery. DCAT is fine for describing datasets but how can you programmatically find them? I know this is something you and Michael have looked at in detail. Anyway... my point in mentioning it is that HTTP Link is a possible part of the solution (as well as /.well-known/ which I hate with a passion for its anti-Web horribleness but accept it's not going to go away, just like accessURL Grrr...)

Here we have a real case where we have one thing that has a clear relation to another. Moreover, the first thing doesn't have an easy declarative way of saying "look over there for stuff you might want too" within it. Therefore HTTP Link is, I think, very much in play as a possible solution.

Please don't throw the baby out with the bath water. Put it to a WG vote and see what happens. If I were in the WG, I would vote for the creation of a new @rel type and possibly a new MIME type for a context file. It's not that much work to put in the spec although of course that's the easy part. It's the software to recognise it that's important.

That's what's needed and I'm struggling to understand lanthaler's continued support for describedby when, AFAICS, he's a lone voice. I've been there, done that, and moved on (see accessURL above!). And hey, I defined describedby so I'd like to see it used everywhere - but only where it's the right thing to do which I don't think this is. I can see how you'd force its use, but no overwhelming reason to do so.

A bit of process... a WG member can make a formal objection (http://www.w3.org/2005/10/Process-20051014/policies#WGArchiveMinorityViews) which triggers a Director review. What would happen is that the WG would vote to go to the next stage with the text written in line with the majority view but the Director would then consider the formal objection (raised presumably by the losing party) and take a decision.

Why do I care? Nothing to do with POWDER I assure you. It's because HTTP Link is a good feature of the Web that should never have been removed. It should just be a normal everyday part of any user agent and right now it isn't. I'd like that to change. It would help JSON-LD and many other things too. It keeps coming up and people say "oh well, I'm sure how widely implemented that is..." and go off. Make it useful, use it properly, and people will implement it.

@msporny
JSON-LD Public Repositories member
msporny commented Nov 15, 2012

O_o - just saw this thread... haven't read it in detail. There seems to be legitimate points on both sides... can we have a back-up plan: Just define a new relationship if describedby and transformation don't work for us? Maybe something like, 'context'? Where the definition of context is something like: 'an external document, when combined with the referring document, results in a deeper interpretation of the contents of the document'?

We may want such a feature for RDFa 2.x, to load a set of external prefixes and terms? Trying to phrase it in a way where other languages can re-use it.

@philarcher

What does context mean outside JSON to JSON-LD? If there's an answer for that, then context is a perfect @rel type. If it only has meaning in this context (no pun intended) then I'd say it's a bad one. @rel types should be very generic and certainly not technology-specific. Even 'stylesheet' isn't technology-specific.

@msporny
JSON-LD Public Repositories member
msporny commented Nov 15, 2012

@philarcher 'context' is an external document that gives you new insight, or a deeper understanding, of the contents of the current document.

@gkellogg
JSON-LD Public Repositories member

We re-examined describedby in the past. I agree that if we can find a better link relationship, we should use it. The problem is, that in some sense, a context does describe a document; the difference is that the document already is metadata, so that the description is more like meta-metadata. But, not in the sense that IANI seems to intended descrdibedby to be used.

+1 to come up with, or find an existing, link relationship term that indicates that the link is to necessary processing information to process it.

Regarding a separate MIME type for context documents, we already has an optional parameter on application/ld+json. The profile, although that might be intended for a different purpose, as a context definitely does change the semantics of the document. But, given that a context is a JSON-LD document, and any JSON-LD document containing a context may be used as the context for another document, using application/ld+json seems right. Perhaps there should be an additional parameter, in which case it should probably match the @rel type.

@lanthaler
JSON-LD Public Repositories member

No need to wait for last call @cygri, just as any other issue we will discuss it in one of our next telecons. If the majority of the group thinks that would be a wise thing to do, I simply accept that fact. I was (just as you) expressing my own personal opinion and so far you haven't convinced me that the use case you describe is more important or even clearer than the use case we use describedby for at the moment.

Let me try to explain one more time the reasons why I'm somewhat hesitant to change describedby:

  • the only other rel values that have been mentioned as alternative have been profile and transformation. We had the discussion about profile already and concluded that profile has different semantics. Even Erik Wilde who is the one working on its specification agreed that profile's intended use is different. I also don't think transformation would be a good choice because it is not a transformation in the sense of XSLT as used in GRDDL for instance. Furthermore it is not standardized. I explicitly asked you Richard for an alternative but till now you didn't provide one

  • the way describedby is currently specified does cover our use case; IMO at least. Given that I don't have the final voice on this I sent a mail to the IETF link-relations mailing list asking for their opinion.

  • the official definition of describedby is

    Refers to a resource providing information about the link's context.

  • I think the term "context" covers our use case, but you disagree and refer to the dictionary. Since I know that my English skills aren't perfect, I went and checked myself and found enough examples that apparently seem to cover our use case. The fact that Manu is proposing to use context as alternative relation type tells me that I'm not alone with that interpretation.

  • the way we use describedby only specifies how a JSON-LD processor should interpret a describedby link header found when dereferencing a JSON document. We do not impose any other restrictions. Therefore I don't see how this prevents the use case you are worried about. What should a processor do instead? Go, fetch the referenced JSON-LD document, and output that instead? To make this point even clearer, what should the output of something like this be: JsonLD::expand('http://alice.example.com/addresses.json')

All that being said, I'm still open to be convinced to the contrary. However, convincing me to completely remove this feature will be close to impossible as I think it is way too important.

@tidoust
@lanthaler
JSON-LD Public Repositories member
@tidoust
@lanthaler
JSON-LD Public Repositories member
@lanthaler
JSON-LD Public Repositories member

Sorry, forgot this in the last mail

In the end, even though it's not harmful, it's a waste of resources: it means an additional round-trip, cpu and memory used for nothing.

What exactly did you mean by this statement? That's a general "problem" (please note the quotes around "problem") of RDF as it doesn't expose any semantics at the HTTP level in the form of media types, i.e., there's no way to know what you'll get or express what you want before you actually GET it.

What's the problem if you don't find what you hoped to find? That happens all the time on the Web and you have to be prepared to that anyway. What if you get back statements using a vocabulary you don't understand? Is that any better?

@lanthaler
JSON-LD Public Repositories member
@tidoust
@tidoust
@lanthaler
JSON-LD Public Repositories member
@msporny
JSON-LD Public Repositories member
msporny commented Nov 16, 2012

@lanthaler You are correct, in that we don't /need/ to mint a new term and could just format the JSON-LD document linked to via describedby in a certain way as to support each use case you outline above. I also don't think that the use of 'context' in 'describedby' is being used in the way that we're using it now... or rather, it's use is vague and could be interpreted in both ways. It's ambiguous. That said, there is a potential for an author to miss this fine point. I don't think @cygri's use case will be very common, but if there is a chance that 'describedby' will be misunderstood, then we should try to find an alternative. Introducing potential ambiguity on the Web, especially wrt. Linked Data is a bad thing. In general, we should try to avoid it.

PROPOSAL 1: Retain the ability to specify a JSON-LD context via the 'Link' HTTP header. Mint a new term for the 'describedby' relationship and register it with the IETF.

PROPOSAL 2: The 'context' relationship replaces the 'describedby' relationship as the mechanism that is used to instruct the JSON-LD processor on which context it should use to interpret the document.

@cygri
cygri commented Nov 16, 2012

Some choice quotes from RFC 5988:

[Registered relation types] SHOULD be appropriate to the specificity of the relation type; i.e., if the semantics are highly specific to a particular application, the name should reflect that, so that more general names are available for less specific use.

That's exactly the problem here: JSON-LD tries to overload a general name with highly application-specific semantics.

A link can be viewed as a statement of the form "{context IRI} has a {relation type} resource at {target IRI}, which has {target attributes}".

That clears up what the term “context” means in the describedby registration.

Applications that don't wish to register a relation type can use an extension relation type, which is a URI [RFC3986] that uniquely identifies the relation type.

We like things to be identified by URIs around here, don't we?

PROPOSAL 3: The rel=http://www.w3.org/ns/json-ld#context relationship replaces the 'describedby' relationship as the mechanism that is used to instruct the JSON-LD processor on which context it should use to interpret the document.

@msporny
JSON-LD Public Repositories member
msporny commented Nov 19, 2012

@cygri - I took the liberty of expanding your proposal to something we could put into the minutes.

PROPOSAL 1: +0.7
PROPOSAL 2: +0.6
PROPOSAL 3: +1

@lanthaler
JSON-LD Public Repositories member

I know that http://www.w3.org/ns/json-ld doesn't have to be dereferenceable but we should practice what we preach, so my question is: What can we put up there? Will we have support for conneg?

I would like it to dereference to a JSON-LD or HTML document depending on the Accept-header. The content would basically just be a description of the feature. Is that be possible? Who can we ask?

@tidoust
@msporny
JSON-LD Public Repositories member
msporny commented Nov 19, 2012

We already do something like this for RDFa, so there is a precedent.

@niklasl
JSON-LD Public Repositories member
niklasl commented Nov 20, 2012

I am in favour of a new IRI unless anyone manages to dig up something existing. It's a pity that neither transformation nor profile are media-type agnostic enough. What might become a pity is if we do the same, and define something too narrow and specific. Especially if we also get it registered as an IANA link relation (since I believe the proliferation of that may hurt general web interoperability).

@tidoust
tidoust commented Nov 20, 2012

Agree with @niklasl. I also note the link relationship is only available to users that know how to tweak HTTP headers. No matter how simple this may sound, that remains something technical. In that context, I don't think it is such a big deal to require using an IRI instead of a simple word.

PROPOSAL 1: +1 without the new term registered with the IETF
PROPOSAL 2: -0.5
PROPOSAL 3: +1

@gkellogg
JSON-LD Public Repositories member

PROPOSAL 1: +1
PROPOSAL 2: -0.5
PROPOSAL 3: +1

@lanthaler
JSON-LD Public Repositories member

RESOLVED: Retain the ability to specify a JSON-LD context via the 'Link' HTTP header.

RESOLVED: The rel http://www.w3.org/ns/json-ld#context relationship replaces the describedby relationship as the mechanism that is used to instruct the JSON-LD processor on which context it should use to interpret the document.

@lanthaler
JSON-LD Public Repositories member

For the sake of completeness (and not in an attempt to reopen this issue!) here's the response from Mark Nottingham regarding the use of the describedby link relation:


First of all, link relations are explicitly NOT linked to any particular media type -- so the argument that describedBy is exclusive to POWDER -- assuming that means a media type -- is misfounded.

Indeed, POWDER itself says:

This is a generic relationship type that does not of itself imply that the link points to a POWDER document — that is done by the specific Media type.

The definition of describedBy is:

Refers to a resource providing information about the link's context.

That's it. This is quite vague; some relations are.

Personally, it if were me, I'd want a relation type that is more concrete, but if describedBy works for you, go for it, I'd say.

Cheers

@lanthaler lanthaler added a commit that referenced this issue Nov 21, 2012
@lanthaler lanthaler Use "http://www.w3.org/ns/json-ld#context" instead of "describedby" l…
…ink relation

This addresses #197.
6f0bc8b
@lanthaler
JSON-LD Public Repositories member

I updated the spec in 6f0bc8b to use the http://www.w3.org/ns/json-ld#context link relation instead of describedby.

If I do not hear any objections within the next 24 hours I will go ahead and close this issue.

@lanthaler lanthaler added a commit that referenced this issue Nov 21, 2012
@lanthaler lanthaler Add issue marker that http://www.w3.org/ns/json-ld#context isn't regi…
…stered yet

This addresses #197 and #199.
6458c99
@lanthaler lanthaler closed this Nov 22, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.