search

databio / bioterms

Content and Dockerfile for the bioterms.org site
http://bioterms.org
1 stars 0 forks source link

nicely formatted pages #5

Open nsheff opened 5 years ago

nsheff commented 5 years ago

With schema.org, you can get the jsonld-formatted page: https://schema.org/Person.jsonld or the nice human-readable version: https://schema.org/Person

I'm guessing this is done programatically. How can we do this with bioterms?

nsheff commented 5 years ago

SO, right now we are just listing files and serving those files (http://bioterms.org/schemas/#).

I wonder if we could use jekyll for this.

Or, better yet, just use the system that schema.org has already developed that does this:

https://github.com/schemaorg/schemaorg/blob/master/SOFTWARE_README.md

oddodaoddo commented 5 years ago

I think the schema.org software depends on two things (if I understand correctly): 1) Google appengine and 2) schemas are represented as rdf

I think maybe we need to look at another way to make the json-ld look pretty.

nsheff commented 5 years ago

why? It seems like it would be easier to just satisfy those 2 dependencies and then make use of what they've already done, doesn't it?

oddodaoddo commented 5 years ago

;) I am not much of an rdf writer so I would have to spend more time rewriting the schemas into rdf than the guy next door who has spent considerable time with it ;). Also, I have little experience with Google app engine. I admit I have not spent much time trying to figure out what exactly the appengine dependency is - if it is as simple as importing a module or creating an account with Google - great, if it is more involved than that, it may prove to be a time sink for me. I do not mind converting the jsonld to rdf but it will take me a few hours...

nsheff commented 5 years ago

Ok I think you're probably right. their thing is not really meant for general purpose use... they say:

Internally, the app uses a simple RDF-like graph data model, and has a parser for the RDFa Lite subset that we use to represent schemas. Potential contributors are cautioned that this code is not designed to become a general purpose framework, and that we're comfortable with it being hardcoded in various ways around the needs and approaches of schema.org.

So it's probably best for us to just roll our own, something much simpler.