Json-ld not being converted to RDF as expected - json-ld

I've converting some JSON-ld to RDF however it doesn't seem to produce RDF with the subject as I'd expect.
So, my JSON-ld looks like this:
{
"#context":{
"personid":"http://schema.org/id",
"hasUpdateType":"http://schema.org/updateType"
},
"#type":"http://schema.org/Person",
"personid":"123456",
"hasUpdateType":{
"#type":"updateType",
"updateType":"Full"
}
}
And the RDF that is produced is
_:b0 <http://schema.org/id> "123456" .
_:b0 <http://schema.org/updateType> _:b1 .
_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema.org/Person> .
However I was expecting something like (syntax not correct, just trying to show roughly):
person hasUpdatetype Full
Is my json-ld wrong?
To make the conversion from json-ld to rdf, I'm using the toRDF() from this library https://github.com/digitalbazaar/jsonld.js
Any help would be appreciated.
Thanks.

You need to use #id (or an alias) to define the subject of the node object. You could potentially defined "persondid" as #id in the context.
You defined "hasUpdateTime" to expand to "schema:updateTime", so the expanded RDF should use "http://schema.org/updateType" as the predicate. If you want the value to be a single URI associated with "Full", use type coercion on "hasUpdateType". Something like the following may be closer to what you want.
{
"#context":{
"#base": "http://example.com/",
"personid":"#id",
"hasUpdateType": {"#id": "http://schema.org/updateType", "#type": "#id"}
},
"#type":"http://schema.org/Person",
"personid":"123456",
"hasUpdateType":"Full"
}
This would give you the following triples:
<http://example.com/123456> <http://schema.org/updateType> <http://example.com/Full> .
<http://example.com/123456> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema.org/Person> .

Related

Embedding a path in the parameter of sh:lessThan

Connected to this question (and its previous ones):
Using sh:maxExclusive to compare (the values of) two datatype properties
I created a small ontology with three classes: DataSubject, MemberState, and Minor. There are two datatype properties: has-age and has-minimalage. The former is from DataSubject(s) to integers, the latter is from MemberState(s) to integers. Then there is an object property has-member-state from DataSubject(s) to MemberState(s).
Now we have the following individuals:
ontology:John
rdf:type ontology:DataSubject ;
ontology:has-age "20"^^xsd:positiveInteger ;
ontology:has-member-state ontology:Spain ;
.
ontology:Spain
rdf:type ontology:MemberState ;
ontology:has-minimalage "16"^^xsd:positiveInteger ;
.
And I want to write a SHACL rule saying that each DataSubject whose age is less than the minimal age of his member state is also an individual of the class Minor.
In light of the replies I got to my other questions, I tried:
sh:rule [
rdf:type sh:TripleRule ;
sh:condition [
sh:property [
sh:path ontology:has-age ;
sh:lessThan (ontology:has-member-state ontology:has-minimalage)
] ;
] ;
sh:subject sh:this ;
sh:predicate rdf:type;
sh:object ontology:Minor ;
] ;
Which does not work: it classifies John as Minor, but 20 is not less than 16. Of course I tried many other variants, e.g., "sh:lessThan[sh:node[sh:path (ontology:has-member-state ontology:has-minimalage)];];", many of which do not probably make any sense, but none of them work.
Can someone suggest me how to embed a path in the parameter of sh:lessThan?
I am sorry if I start being annoying with all these questions :-( I am new to SHACL and SPARQL but I am really trying my best to learn them out of all what I can find on the Web.
Thanks
Livio
The official spec is (hopefully) pretty clear that the values must be IRIs, i.e. only direct properties are permitted. You can however try to revert the logic and use a path at the property shape. Otherwise, fall back to SPARQL.

Object id is missing in Django framework when posted from AngularJS MongoDB

I am posting the following object
{
skillName : "Professional Skills"
_id : {$oid: "5adf23946ab671bf6cb36aff"}
}
to the DjangoService given below:
#csrf_exempt
#api_view(['GET','POST'])
def saveSubjectView(request): #this service will add & update Subject
if request.method == 'POST':
try:
stream = StringIO(request.body)
subject = JSONParser().parse(stream)
print("The subejct is ")
pp.pprint(subject)
serializedsubject = json.loads(json_util.dumps(subject))
print("serializedsubject")
pp.pprint(serializedsubject)
The output that I am getting is
'skillType': { u'_id': { }, u'skillName': u'Professional Skills'}
The ObjectId posted from the front end (AngularJS) is not printed in the service. I know that I can fix it by removing the $oid while posting from the AngularJS application. But I would like to know why this is not happening. I have searched the documents and I couldn't get a proper reply. May be the keywords I used are wrong. Keywords used are : "JSON serialisation of ObjectId", "$oid json serialization using Django".
The complete object I am posting to the Django service is given below:
Exactly. $oid or anything prefixed with $ is an internal format and reserved, so you cannot post field names. The convention is from MongoDB Extended JSON where such prefixes are used to identify the BSON Type for proper conversion, and used as a serializable transport since these "types" are not supported in basic JSON.
So the solution is to actually use the bson.json_util to "deserialize" the JSON string right from the start:
from bson import json_util
# serializedsubject = json.loads(json_util.dumps(subject))
serializedsubject = json_util.loads(request.body) # correct usage
Or more succinctly self contained:
input = '{ "skillName" : "Professional Skills" ,"_id" : { "$oid": "5adf23946ab671bf6cb36aff"} }'
json_util.loads(input)
Returns
{u'skillName': u'Professional Skills', u'_id': ObjectId('5adf23946ab671bf6cb36aff')}
This correctly casts objects from any keys notated with the Extended JSON Syntax to their correct BSON Type, as also supported in the driver functions. And naturally the driver will then convert back to BSON when sending to MongoDB.
If for some reason your request.body contains anything other than a "string" which is valid for input to the function, then it is up to your code to convert it to that point. But there should be no need to "parse to JSON" and then "stringify" again just to input to the function.
NOTE: If you have not already done so within your JavaScript client side of the application, there is also the bson package available. This would allow where such Extended JSON is "received" from the server the translation into the BSON Types as JavaScript Objects, and of course then the serialization of such objects back into the Extended JSON Format.
This would in fact be recommended where "type" information needs to be maintained with the data transmitted and kept between client and server.

How to represent conditional sentences in OWL ontology?

For example,
If weather permits, I will go hiking.
Classes:
Weather
Hiking
Individual:
I
Properties:
permit
go
You could say that if there is a weather condition at time t which is sunny where you are, then there will be a hiking event at the same time involving you. A example of the kind of data you may have is:
ex:2017-02-23 a wc:WeatherCondition;
t:time "2017-02-23"^^xsd:date;
p:place ex:theAlps;
wc:cloudiness wc:sunny .
ex:i p:located [
a p:LocationAtTime;
p:location ex:theAlpes;
t:time "2017-02-23"^^xsd:date .
] .
ex:hiking2017-02-23 a ae:HikingEvent;
t:time "2017-02-23"^^xsd:date;
ae:participant ex:i .
You would like a rule like:
?wc a wc:WeatherCondition;
t:time ?t;
p:place ?p;
wc:cloudiness wc:sunny .
ex:i p:located [
a p:LocationAtTime;
p:location ?p;
t:time ?t .
] .
implies:
[] a ae:HikingEvent;
p:location ?p;
t:time ?t .
I don't think this is doable in OWL. However, you could use a rule engine for this. Nonetheless, I am not sure that this kind of use case where the data is highly contextual and dynamic is best covered by semantic web standards.

When isn't an IRI enough of a value in JSON-LD?

I'm playing around with JSON-LD but I think I'm missing something about linking. Gregg Kellogg's answer to Repeat whole JSON-LD structure or only the ID? almost clears it up for me, but not quite.
He has an example like this, where the author is an organization:
{
...
"author": {
"#id" : "http://example.com",
"name": "My Organization"
}
}
Which he simplifies at the end to look like this:
{
...
"author": {"#id" : "http://example.com"}
}
It seems to me that if I wanted to link to something, I should be able to simply reference it:
{
...
"author": "http://example.com"
}
That value would be seen as an IRI (assuming author is defined correctly) and that something would inflate the object at that IRI. However, almost all of the examples I see have extra stuff around that. What am I missing here? What can't I do if I just use the IRI instead of the method Gregg uses? He says that some people repeat parts of the graph, but that would seem to be a huge problem in managing data should I have to change a name. Is there a practical or theoretical problem there?
The sample on json-ld.org seems to be what I expect, but the things I've seen most often don't do it like this (linking to spouse):
{
"#context": "http://json-ld.org/contexts/person.jsonld",
"#id": "http://dbpedia.org/resource/John_Lennon",
"name": "John Lennon",
"born": "1940-10-09",
"spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
I think in the end if doesn't matter because Markus Lanthaler also notes that you can't rely on parsers to inflate objects so you're stuck specifying everything all the time just in case.

SQL Like in OWL API for data properties

In OWL API, classes may have data properties. For e.g. a class may have a date property hasCommonName "Something". In OWL API, is there any facility like the SQL like which allows querying for classes that hasCommonName containing the word "Some", just like SQL like behave
You can use regular expressions to identify the things you need. Consider the following knowledge base:
DataProperty: hasCommonName
Individual: foo
Facts:
hasCommonName "Something"
You can retrieve the individual foo by using the following class expression: hasCommonName some string[pattern "Some.*"]. The string[pattern "Some.*"] specifies the pattern to be matched. Warning, currently not supported by all reasoners (works for Hermit 1.3.7)
You need to look at some SPARQL tutorials. You can write something like this:
SELECT * WHERE
{
?pizza rdfs:subClassof [
owl:onProperty :hasTopping;
owl:someValuesFrom :TomatoTopping ] .
}
Basically, you need to define the correct predicate based on your restriction.

Resources