-
Notifications
You must be signed in to change notification settings - Fork 114
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Proper semantic type support #343
Comments
@pwalsh very sound suggestion. I think we may want to think a bit further about whether rdfType offers some value before we deprecate. One important point: is this post or pre v1? |
post v1. |
Hi, I need to study better all issues here... But there are perhaps an alternative, preserving |
@ppKrauss i definitely think expanding |
Hi @rufuspollock, I am trying to create a dedicated issue, see #451. Hi @danfowler, your example is a kind of "datatype defined by URL" (?)... Perhaps, to avoid confusion in the semantic-use of |
Since rdfType is limited to an rdfs:class it is often redundant:
The rdfProp here #451
->
In general, a more comprehensive approach that does not work on each single field but on the whole table |
Mapping tabular data to RDF should build on JSON-LD. Maybe we can define a mapping from Table Schema to a JSON-LD context document and a way to transform tabular data using this schema to JSON which can then be transformed with the JSON-LD context. May sound complicated but less complicated than defining a custom method of mapping from tabular data to RDF. |
@nichtich in Italy we are publishing APIs using this specification to bridge JSON Schema and JSON-LD using JSON-LD Framing https://www.ietf.org/archive/id/draft-polli-restapi-ld-keywords-03.html An easy way to integrate with this specification, is the following:
These slides provide some more context https://docs.google.com/presentation/d/1o__StiDhbNEfB0Htf-lsTtLm8zzSXmLiyD9QSKxkXIQ/edit#slide=id.g13c8404df7f_0_24 cc: @mfortini |
I wrote:
Actually it only requires an optional root property {
"@context": {
"foaf": "http://xmlns.com/foaf/0.1/",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"name": "foaf:name", // term definition in root context
},
"fields": [
{ "name": "name", "type": "string" }, // term definition given above
{
"name": "age",
"type": "integer",
"definition": { // term definition inline at the field
"@id": "foaf:age",
"@type": "xsd:integer"
}
},
{
"name": "homepage",
"type": "string"
"definition": {
"@id": "foaf:homepage",
"@type": "@id"
}
}
]
} This can be combined into one JSON-LD context: {
"@context": {
"foaf": "http://xmlns.com/foaf/0.1/",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"name": "foaf:name",
"age": {
"@id": "foaf:age",
"@type": "xsd:integer"
},
"homepage": {
"@id": "foaf:homepage",
"@type": "@id"
}
}
} The content of |
Hi @nichtich, I think there's more than meet the eyes. For example:
I think that we could consider an extension to Table Schema based on LD Keywords, provided some interoperability checks. Another option could be to use JSON-Schema instead of Table Schema for this use case: this could benefit people that need to publish REST APIs based on frictionless data. WDYT? |
Hey @nichtich @ioggstream I'm not sure about this. This is actually an issue I started 7 years ago and to my knowledge there is very little interest in really trying to add comprehensive RDF/JSON-LD support directly to the specs, which is where the recent discussion has led. Do we really need it in the spec, and why? I think it would be very cool if we have implementations or published patterns on mapping, say, Table Schema to JSON-LD. And possibly some of the work @akariv did on column types for Fiscal Data Package ref. which does have a semantic concept layer, could be useful as a more general starting point. |
@ioggstream good points. We can use another name but
Sure there are alternatives to Table Schema specification and we should not try to fully reinvent them. If support of information how to map tabular data to RDF is possible without much complexity, I'd argue to include it in the specification, nevertheless.
I don't see a use case as most parts of JSON-LD context can already be specified in JSON-LD term definition. In short, the root element |
In Italy, there was the idea to standardize CSV data exchanges between agencies using frictionless: I think @mfortini is still working on that. Since public sector data can be complex, the idea was to have a general and reliable solution capable of covering most of the use cases. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Context
I raised having a model spec in frictionlessdata/frictionlessdata.io#854 as
model
in Fiscal Data Package is basically a way to declare semantic types over one or more resources, and it is very very useful and generally applicable.Recently, I'm diving into
rdfType
on the JSON Table Schema spec, and the way it is specified there is not very useful:I think we should:
rdfType
as a field-level property in the JSON Table Schema specmodel
specmodel
to be declared on a resource (map multiple fields in a single resource to higher-level concepts), and on a package (map across multiple resources)We have a real living use case for this right now in Fiscal Data Package, and we also have some implementation if it in OpenSpending which is not yet officially in the specification.
I have two short term goals here:
SHOULD
semantic types, in line with the great work on OBEU Data Model, and the work that @akariv has done with OS Data Types.The text was updated successfully, but these errors were encountered: