search

FamilySearch / gedcomx

An open data model and an open serialization format for exchanging genealogical data.
http://www.gedcomx.org
Apache License 2.0
356 stars 67 forks source link

Non-resolvable URIs #310

Open gmr opened 6 years ago

gmr commented 6 years ago

I've been working on building out a Python 3 library for gedcomx and am looking to extend it for DNA tests and expressing genetic relationships.

I've noticed none of the URIs for any of the data types in the spec that are under the gedcomx.org domain are resolvable. Is this an intentional behavior and just a convention to use the gedcomx.org domain for "fake" URIs as a namespacing behavior? If publishing extensions, should I be making the URIs publicly resolvable?

Finally, while I imagine that I would have found it in the amount I've been digging around, but are there machine readable formatted (XML, JSON, etc) versions of the specs?

Ideally with the URI namespaced specs, asking http://gedcomx.org/Date in a browser would return HTML, if requested with Accept: application/json, it would return the date spec in JSON, etc.

Thoughts?

stoicflame commented 6 years ago

I've been working on building out a Python 3 library for gedcomx and am looking to extend it for DNA tests and expressing genetic relationships.

Awesome.

You know, you might want to drop a line to @misbach, who has some ideas around the same thing. I'd love to see a proposal for an enhancement or extension to support DNA testing.

I've noticed none of the URIs for any of the data types in the spec that are under the gedcomx.org domain are resolvable.

Well, that's not entirely accurate. If I go to http://gedcomx.org/Birth, I get redirected to a page that describes the controlled vocabulary element. I wouldn't be surprised if we missed some, but we've tried to put something there where possible.

The convention of using a URI to identify controlled vocabulary elements is pretty standard around the industry, coming out of concepts from the semantic web and stuff. The problem is that what those URIs are supposed to resolve to hasn't really been standardized. For now we redirect to an HTML page with semantic markup in case a computer ever wants to parse it.

If publishing extensions, should I be making the URIs publicly resolvable?

It's up to you.

If you're proposing an enhancement to the gedcomx spec, then you should probably propose a new controlled vocabulary element in the http://gedcomx.org namespace. If you're just publishing your own extension, you'll probably want to use a URI in whatever domain you control.

At FamilySearch, we have a bunch of extensions that look like http://familysearch.org/types/CustomFSType.

Finally, while I imagine that I would have found it in the amount I've been digging around, but are there machine readable formatted (XML, JSON, etc) versions of the specs?

There's a XSD that kinda describes the model at http://www.gedcomx.org/gx.xsd, but it's not canonical and might be inaccurate or out of date. I'd have to take some time to look into it.

Ideally with the URI namespaced specs, asking http://gedcomx.org/Date in a browser would return HTML, if requested with Accept: application/json, it would return the date spec in JSON, etc.

I agree that's probably the ideal, but it would take a significant effort and there really isn't a big demand for it yet. Then there's also the issue of what IDL to use (JSON Schema, I assume?) and the question of why semantic markup isn't adequate for the requirements.

Thanks for dropping a line and opening the thread!