RFC0018: Context resource

[arnau]

Context

Currently, the register metadata is not exposed consistently. Some is exposed
via the register resource, some via the field register and some from the
register register.

Changes proposed in this pull request

This RFC proposes a context resource to surface the metadata of the register.

Meanwhile there is no versioning defined for metadata treat this as single
versioned.

Dependencies:

• RFC0013: Multihash

Note: It obsoletes #27

Addresses #17

[MatMoore]

I think I agree with the direction this is going in, but I have a bunch of questions, so let me know if it's easier to discuss this in person.

[MatMoore]

I think this is the first time registers have linked to other registers by URL.

This could cause problems if that URL breaks but the register is still available elsewhere.

Another way of doing this would be to use a CURIE then rely on a catalog to resolve this to something (and this could be a catalog outside of GDS's control if GDS is no longer hosting the register register). Although then you couldn't replace a register with a non-register.

[arnau]

Well, it is the first time indeed, the intention of this is to point to the successor which should be a fixed and clear appointment. I imagine the situation you describe being resolved by a regular HTTP 301 redirection. I'm not sure the indirection added by a CURIE is worth it.

[MatMoore]

Fair enough 👍

[gidsg]

Right now I cannot see where this information would be persisted? Is there a companion to this that addresses how this is represented in RSF/Entry log? If not I think this should be pulled out into a separate RFC that describes Status and its representation.

[gidsg]

@arnau please can you address this comment?

[arnau]

@gidsg status must be part of the register metadata which means it has to be encoded in RSF. The way to express that will highly depend on the metadata solution we end up having but, if it is in line with what we have right now it will be an system entry with the appropriate key pointing to a blob with these information.

[gidsg]

This seems like what we refer to in other place as fields is there a deliberate attempt to move away from this to schema? If so we should be consistent across other instances e.g. RSF. if not, we should call it fields

[MatMoore]

I'm also wondering whether this would prevent us from supporting another metadata standard.

For example, if we wanted to provide things like csvw or json schema it would be great if we just had one resource and you can request the standard you want, using content types. But I'm not sure if that would fit this model where the schema is part of a larger object.

[arnau]

@MatMoore I did the research on using json schema or csvw schemas and json-ld related and the result is that Registers is not really 100% compatible with them due our primitives. Both csvw and json-schema let you define your own patterns which could work for us as a sort-of compatible translation but it's messier than it seems.

Now, particularly with csvw, it allows to provide schema + context although probably not everything this context resource is offering. I'm not sure it's worth it extracting (again) the schema just because of that.

@gidsg It is deliberated indeed. The "fields" approach builds on a central vocabulary held in the fields register and it has been proven a mistake. Moving away from this central model to a local schema definition predates me, but I totally agree with it.

Changing terminology to schema and attributes is important because a) it's not the same and b) when it is (i.e. field vs attribute) I want to be able to talk about previous concepts with minimal confusion.

RSF is something we can change when we are ready and comfortable but to my eyes it is not important enough to reject or hold this RFC. After all, RSF is an internal format that so far has not even a stable specification.

[MatMoore]

I think this all makes sense so I'm going to approve the PR, but it did make me wonder whether we are ruling out things like csvw with this API. I haven't thought too much about it but it would be good to discuss this at some point before we implement.

[MatMoore]

I was wondering if we actually need this. When we've implemented multihash, I think you should be able to determine the hashing algorithm used by looking at its root hash.

[arnau]

I think it's a nice thing to offer and not at a big cost. Why do you think it shouldn't be there? The fact that you can infer it doesn't mean it is useless or harmful.

[MatMoore]

Fair enough, it's just a general preference for less information returned but I don't have strong opinions about this.

[MatMoore]

I'm also wondering whether this would prevent us from supporting another metadata standard.

For example, if we wanted to provide things like csvw or json schema it would be great if we just had one resource and you can request the standard you want, using content types. But I'm not sure if that would fit this model where the schema is part of a larger object.

[arnau]

I'm also wondering whether this would prevent us from supporting another metadata standard.

For example, if we wanted to provide things like csvw or json schema it would be great if we just had one resource and you can request the standard you want, using content types. But I'm not sure if that would fit this model where the schema is part of a larger object.

You mentioned three times csvw and json schema so I think it's worth talking about it.

When I started looking for ways to express the schema I started with known standards like json schema and csvw metadata. As it turns out Registers define their own primitive datatypes that are not compatible with XML Schema which is what csvw is based on and it is not compatible either with the defaults of json schema. So, in order to adhere to any of these we have to either express the datatypes in a pattern-oriented manner or change the datatypes we have (I'm ruling this out unless there is no other choice).

I might have missed something essential from json schema or csvw or json-ld contexts that could be used instead of the proposal. Happy to revisit if you have found it.