DataResource with non-rdf DataRepresentation #476
Comments
|
Hi!
We have two properties to define schemas / standards the content conforms to. The current model provides
What is the idea behind this property ? In general, I like your idea with
|
|
Thank you very much for answering, Haydar,
I think I missed those. Does that mean I could in theory use these to point to a specific class, let's say
The idea was to link to a specific class like
I can understand that. My idea was to provide a way that mapping of data using different schemas can be automated. The example used a json schema as it is probably the most widely used plain-text serialization these days. Thus, the representation would include a standardized description of the actual schema. Of course one could imagine maintaining these schema "standards" outside of the IDS like you said. One would have to see how this fits with the RML approach below. Let's again use an example: The endpoint returns JSON blobs which look something like: Now I would like to be able to specify a mapping that allows the automatic conversion of such a json blob into an instance of ex:UserAccount. This is where your last question comes in:
The I hope these explanations helped in understanding my idea. |
|
@trueg thank you for contributing these highly interesting ideas. Indeed there are some things we may have to implement. For now, let me shed a bit further light on what we already have. The current state is that the IDS RAM only prescribes an RDF semantics on the metadata level (i.e., by requiring components to "speak" the infomodel language), whereas on the content/payload level it is merely strongly recommended to use semantic standards. Nevertheless, we have made steps towards enabling the infomodel to talk about the structure and semantics of the content of resources, and I also like your A further requirement in this setting might be that the URI of this root node is the same as the URI of the
|
|
As discussed in our meeting last week I created a full example of a resource with a schema mapping. Please bear with me as this is a long one. Let me start by saying that I build on my original idea but simplified it considerably. There are only two new entities as part of the ids namespace involved (I put them into an ids extended ns for clarity). On to the actual example which I have split up into several graphs (using trig here because I like it), each of which I will go into some more detail on. PrefixesThroughout the graphs I will use the following prefixes: Graph 1: The MediatypeThis is a simple one which I just include for clarity. Graph 2: The Domain OntologyThe following graph describes the domain ontology, in this case it is an excerpt of the hazard warnings. This is the pseudo-standard that consumers should be able to work with eventually and which is the target ontology for the schema mappings below. I went a bit overboard here and added too much detail for an example but I guess you just have to deal with that ;) Graph 3: The Shapes GraphThis is the graph containing the SHACL shapes for the domain ontology as used in the resource definition below. Graph 4: The ResourceThis is the interesting one: it contains the resource definition as well as the RML mapping (a set of rr:TripleMap instances). I simply used the same graph for the resource and the mappings since the cross-reference each-other. Each triple map references the artifact it maps as its source. This graph contains one Graph 5: The IDS ExtensionsFinally we have the two entities which I mentioned in the beginning. I envision these as being part of the Again we have a Graph 6: The ResultJust for clarity I ran the RML engine through the following example: {
"result" : [ {
"cancelled" : true,
"cause" : "Broken down vehicle",
"heading" : 42.2,
"location" : [ [ 42.2 ] ],
"trace" : [ [ 42.2 ] ],
"ts" : 42,
"uuid" : "123456789"
} , {
"cancelled" : true,
"cause" : "Vehicle accident",
"heading" : 42.2,
"location" : [ [ 42.2 ] ],
"trace" : [ [ 42.2 ] ],
"ts" : 42,
"uuid" : "523456789"
} , {
"cancelled" : true,
"cause" : "Slippery road",
"heading" : 42.2,
"location" : [ [ 42.2 ] ],
"trace" : [ [ 42.2 ] ],
"ts" : 42,
"uuid" : "623456789"
} , {
"cancelled" : true,
"cause" : "Heavy rain",
"heading" : 42.2,
"location" : [ [ 42.2 ] ],
"trace" : [ [ 42.2 ] ],
"ts" : 42,
"uuid" : "323456789"
}
],
"next_page_token" : "string"
}As a result we get the following domain-specific RDF blob: And that is it. If you got this far then you have my gratitude. Looking forward to discussing this in more detail very soon. |
HaydarAk
added
the
enhancement
I am trying to describe a connector which provides a typical RESTful endpoint that returns JSON blobs.
Sadly I could not find a way to specify the schema, maybe I am missing something, the examples seem partially out-of-date and partially wrong.
Thus, in the spirit of starting a possible discussion let me provide an idea of how such a thing could be achieved:
Imagine the following resource with a bunch of IDEA tags:
Now as you can see the idea is to provide more than just the SHACL shapes as IMHO they are not sufficient to know what kind of data is returned. We also need the RDF class acting as the actual result type (idea:resourceType).
Given that we know which kind of class the ids:Resource will return, the SHACL shapes describe which properties are included.
The next step is to describe the ids:DataRepresentation which as mentioned before is not RDF, but plain JSON. We can use a json schema definition for that (idea:JsonSchema as a subclass of sth like idea:Schema with other sub-classes like idea:XmlSchema or whatever one needs).
Finally we need to map the json schema to the RDF class referenced on the resource. We can do that via an RML mapping.
With that we have the full round-trip from anything to RDF.
Thoughts? Does this make sense? At least partially? Does sth like this already exist in IDS and I merely missed it?
The text was updated successfully, but these errors were encountered: