New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Turtle dumps on per-term views #317
Comments
I'll hack something towards this. TimBL asked for it, arguing that Turtle is the main format used by RDF / Linked Data people these days. Turtle also has the benefit of using basically the same syntax as the SPARQL query language. These languages are more for developers and experts (e.g. in standards groups or building apps or analysing schemas) than for mainstream publishers/webmasters, for whom json-ld, microdata and rdfa are probably better suited. |
👍 I am seeing the use of turtle in JSON-LD specification work, probably because it contains less syntactic sugar. |
Note that the Turtle spec also has turtle in a script element in HTML, whic my processor gets, although schema.org may never do so. |
Could you folks please make Turtle an option. Using conneg p (or make it the sole format)
|
@timbl what's "conneg p"? I'm planning to implement Turtle versions of the dumps and of the pages, but it will take a little Python work first. |
BTW from my perspective the biggest motivation to use Turtle is that it is effectively the same language as SPARQL, for which there are many databases that can do useful things with both triples and quads. Having basically the same notation for asserting and asking is - amongst other things - a good educational tool. Here is a SPARQL db populated with the last release of schema.org: |
@danbri conneg(p) is Content Negotiation Proactive, I think, described here: http://tools.ietf.org/html/rfc7231#section-3.4.1 But @timbl wrote the original RFC, literally, so he would know better =) |
That seems to be what most of us have been casually calling just 'conneg'. That link says "Proactive negotiation has serious disadvantages" but I think it should be reasonably straightforward here. |
@danbri I would've thought more people would load a JSON-LD dump into a NoSQL database these days, instead of putting turtle in a triplestore. But perhaps I've got the audience for this wrong. |
Btw we also make some use of SPARQL in the schema.org codebase for tests/ unit testing of the schema graph, so I am interested to support more such tooling like the link I shared above. Do take a look... |
Is there anything I can do to help here? If adding a dependency on Would some code that produces a Turtle dump based on this approach be of interest? The templates could obviously be re-used for per-term Turtle views once the other machinery for that is in place. |
I can only second Richard's proposal to use jinja2 templates for serializing; www.productontology.org uses exactly that approach for generating Turtle and RDF/XML with great success. |
A +1 to Turtle availability, ideally as full dump, per-term conneg (so it's web-native) and loaded into a well-maintained SPARQL endpoint. The latter would be particularly useful as it makes it relatively simple to obtain any other required formats (via SELECT and templating/transformation) and mappings, e.g. to OWL, DC, FOAF, GoodRelations etc (via CONSTRUCT). |
See http://schema.org/version/ ... there is an ntriples dump of our last release. Is ntriples still a On Sun, 24 May 2015 11:56 Danny Ayers notifications@github.com wrote:
|
@danja Would Triple Pattern Fragments be an alternative? |
I think the point is that when you want to work with the schema you need to be able to dereference it as Linked Data. RDFa makes this a bit more complicated as many libraries do not properly implement that. I agree that Turtle would probably be the best option for the LD crowd. Triple Pattern Fragments doesn't really help as all we want in the end is to get a machine readable form of the URI which represents either a class or an attribute. |
I think that http://schema.org/docs/schema_org_rdfa.html provides everything that one needs for working with schema.org in a Linked Data environment. The conversion from RDFa to any other RDF syntax is straightforward and properly supported by most if not all RDF libraries for popular programming languages. Maintaining other syntaxes in file form in schema.org would just add redundancy and thus the risk or errors. Doing on-the-fly conversion would put load on the schema.org site which is not really related to the main purpose of schema.org. You can use http://rdf-translator.appspot.com/ or plain RDFlib to convert the RDFa file to any syntax you want. I do not dispute that SPARQL endpoints, dumbs in other RDF syntaxes etc. might be useful for the LOD research community, but I think it is
Anybody can buy a proper domain name (like (linkedschema.org) and provide a respective set of services based on http://schema.org/docs/schema_org_rdfa.html. I am sure it will be broadly appreciated if someone from the LOD community volunteers to develop and operate, in a sustainable form, such a set of services under a domain name of choice. |
In general I think we have underplayed the fact that we have machine-readable schemas, so making efforts to encourage programmatic use of the schemas is worthwhile. I agree that RDFa people ought to be able to run an RDFa 1.1 parser in 2015, but since I'd like to get a version of rdflib into the webapp anyway (so people can run the unit tests without hassle) it could be relatively easy to create a Turtle view of the RDFa in each page. AppEngine ought to be able to handle the load if we cache things. BTW re SPARQL, Dydra's web service UI is pretty handy, e.g. http://dydra.com/danbri/schema-org/ |
Couple of points. We now have rdflib integrated (thanks @RichardWallis). And I've also been generating N-Triples and N-Quads dumps with each release. Currently they're not exposed as schema.org URLs but can be found in the repo under data/releases/ We also have an un-merged but not forgotten PR from @cygri that exposes CSV views of the data, as well as developments around JSON-LD. Once we get the looming v3.0 release out I'd like to prioritize this cluster of issues for our next release, with a rough theme of "making it easier to build things with schema.org data". |
😄 |
Dump level is done - http://schema.org/docs/developers.html see also data/releases/* in the repository for various format snapshots. Do we have an audience here for per-term Turtle? i.e. the same triples as are in RDFa at http://schema.org/Event etc but in Turtle? |
@danbri would love per-Term Turtle! Thanks for the dump, great start! |
+1 |
As probably a person that will be involved if we do implement per-term Turtle, I would be interested in some of the use-cases for it. ~Richard. |
@RichardWallis for me it's part of the Linked Data approach. I often dereference just the particular URI and for that I prefer Turtle over embedded stuff like RDFa. We see more Linked Data apps coming up now and you can do nice stuff like: http://lod.opentransportdata.swiss/didok/BSGB If you click on sameAs it will dereference the referenced URI as Linked Data and embeds in into the current site. Again, RDFa would work as well but probably less implemented in parsers. |
This issue is being tagged as Stale due to inactivity. |
ok - so we had this for a while, but removed it when moving to static hosting. https://schema.org/docs/developers.html offers Turtle downloads. Our source data files are also now Turtle My feeling in retrospect is that @mfhepp was right and per-term turtle lacked concrete usecases. Part of the problem is that schema.org only really makes sense as a whole; per term definitions, by definition, only give a part of the picture. Have any concrete usecases emerged? |
It would be good if per-term page we allowed .ttl or content negotiation to get a simple Turtle description of the term.
See also: #208 on expanding formats
The text was updated successfully, but these errors were encountered: