How to create subclasses

[mary.b...@gmail.com]

Hello!

I have been trying to create a subclass using a file that will be parsed by jsonld. Creating classes works and I am able to see them in a list on Stardog, but cannot see the expected hierarchy. 

I have tried the following syntax, 

'Observation': 
    {
        '@id': 'http://elucidbio.com/CAPgraph/Observation',
        '@type': 'rdfs:Class',
        'children':[ 
            {
                'name': 'Reading',
                '@id': 'http://elucidbio.com/CAPgraph/Observation/Reading',
                '@type': 'rdfs:Class',
                'rdfs:subClassOf': 'http://elucidbio.com/CAPgraph/Observation'
            },
            {
                'name': 'Finding',
                '@id': 'http://elucidbio.com/CAPgraph/Observation/Finding',
                '@type': 'rdfs:Class',
                'rdfs:subClassOf': 'http://elucidbio.com/CAPgraph/Observation'
            }

        ]
    }

With this it seems like 'Reading' and 'Finding' are the highest level class when I would want them to be a subclass of 'Observation'. Are they already subclasses and I just cannot see it, or is something else needed to make them a subclass? Thanks!

[Zachary Whitley]

Can you include the full json-ld file that you're loading? This isn't a complete or valid json document. (the document needs to start with either [ or { and the use of single quotes isn't valid for json documents)

--
-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+u...@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en
---
You received this message because you are subscribed to the Google Groups "Stardog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stardog+u...@clarkparsia.com.

[mary.b...@gmail.com]

Here is the full document.

[Zachary Whitley]

The file you included is actually a python script, not json-ld, although it's meant to encode a json object. I've attached the file after converting it to a valid json document. There appear to be problems  with the json-ld specific syntax. There is no @context section among other issues.

[Zachary Whitley]

I've attached a copy including a @context section and the section from your original post. It serialized to the following turtle.

@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .

<http://elucidbio.com/CAPgraph/Observation>
        <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>  rdfs:Class .

<http://elucidbio.com/CAPgraph/Observation/Reading>
        <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>  rdfs:Class ;
        rdfs:subClassOf  <http://elucidbio.com/CAPgraph/Observation> .

<http://elucidbio.com/CAPgraph/Observation/Finding>
        <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>  rdfs:Class ;
        rdfs:subClassOf  <http://elucidbio.com/CAPgraph/Observation> .

Is this what you were looking for?

[mary.b...@gmail.com]

Hmm... I think I may have phrased my initial question incorrectly.  We don't use this file as a json.  Rather, it is a file used when we add triples, as in:

import context

 expanded = jsonld.expand(data, {'base': ELUCID.iri, 'expandContext': context.elucidbio})

 compacted = jsonld.compact(expanded, context.elucidbio, {'base': ELUCID.iri, 'compactArrays': True, 'graph': True})

Which leads me to the real question.  Presently we are successful in adding classes and properties with no difficulty, except, we do not yet know how to have this result in a class hierarchy.  Presently all classes are under Thing; but our intention is to create a hierarchy.  The question is, how to achieve this, whether by content in our context.py, or thorough another means?

[Zachary Whitley]

You need to declare the subclasses and what they subclassed from. You have two declared subclasses of Observation, there is Reading and Finding. You need to make additional assertions for the other classes that you'd like in the hierarchy. Where you make those declarations, either in your python script or load it into the database by other means, is up to you.

[mary.b...@gmail.com]

Many thanks Zachary. Are you saying that we represented it correctly in context.py? If so, great! However, we still do not see the hierarchy in the admin consoles browser, so we believe there is something else to be done. This is vexing because I am sure it is simple, yet I do not know what is missing. 

[Zachary Whitley]

My pleasure. I'm not sure exactly what you're expecting so I'm not sure if it's correct but it at least appears that you should have two subclasses of Observation.  I can't see exactly what triples you've generated. I don't have access to the python libs to attempt to reproduce what you're doing.

Generating the your data from python to json-ld seems a bit convoluted. Is there a compelling reason to be generating it this way? You might want to consider simply writing out your data in Turtle.

If there isn't very much data you can verify exactly what's in the database by issuing the following command at the CLI

$> stardog data export myDb

[Mary Buckler]

Thank you Zachary. Here I attach the new file with the subclasses as your file had done. The issue isn't reading it out, it seems more basic, because even the browser doesn't show it. So I don't see how Turtle would help.  One thing I've noticed is that the current file seems to be no change relative to where I started, suggesting perhaps that the whole context is somehow not even being used.  Can you please take me through the basics? Don't assume I know this; I am just starting.

You received this message because you are subscribed to a topic in the Google Groups "Stardog" group.
To unsubscribe from this topic, visit https://groups.google.com/a/clarkparsia.com/d/topic/stardog/Bu-axDR9gxI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to stardog+u...@clarkparsia.com.

[Zachary Whitley]

Yes, I agree that the problem is probably more basic. The reason I suggested dumping the database and is that I suspect that you're not actually loading any data or at least not loading what you think you are and dumping the db contents would confirm what actually made it into the db. I don't have a complete picture of your process so this is still speculation but I don't think your process of generating your json-ld is actually producing anything or at least not what you think it's producing. 

I would examine the output of your processing step prior to loading the data to confirm that you have what you're expecting or cut that step entirely and simply define your data in turtle. 

<context.py>

[Larry Martell]

I am a colleague of Mary's. If we have data that has '@type':
'Finding' and a context that has this:

'name': 'Observation',
'@id': 'http://elucidbio.com/CAPgraph/Observation',
'@type': '@rdfs:Class',
'rdfs:subClassOf': 'http://elucidbio.com/CAPgraph/Thing',

'children': [
{
'name': 'Reading',
'@id': 'http://elucidbio.com/CAPgraph/Observation/Reading',

'@type': '@rdfs:Class',

'rdfs:subClassOf':
'http://elucidbio.com/CAPgraph/Observation'
},
{
'name': 'Finding',
'@id': 'http://elucidbio.com/CAPgraph/Observation/Finding',

'@type': '@rdfs:Class',

'rdfs:subClassOf':
'http://elucidbio.com/CAPgraph/Observation'
},

]
}

and we call:

expanded = jsonld.expand(data, {'base': ELUCID.iri,

'expandContext': self.context})

What would you expect expanded to contain?

This:

'@type': [u'http://elucidbio.com/CAPgraph/Finding']

or this:

'@type': [u'http://elucidbio.com/CAPgraph/Observation/Finding']


In our case we get the former. Is that the problem? Should our data
have '@type': 'Observation/Finding' ?

[Evren Sirin]

Are you not seeing your classes in the schema browser of the
webconsole? The webconsole retrieves classes that are explicitly typed
as owl:Class or that have been asserted to have instances themselves.
I don't know about the details if your JSON-LD generation but you
should use owl:Class instead of rdfs:Class in there.

Best,
Evren

[Larry Martell]

No, we do not see the classes in the webconsole. When we add a finding
we just see a finding and we do not see any observations.

If we were to change rdfs:Class to owl:Class in our classes, would we
also have to change the occurrences of rdfs to owl here as well?

'@context':{
'rdfs': 'http://www.w3.org/2000/01/rdf-schema#',
'rdfs:Class':
{
'@id': 'rdfs:Class',
'@type': '@id'
},
'rdfs:subClassOf':
{
'@type': '@id'
},
'sameAs':
{
'@id': 'owl:sameAs',
'@type': '@id'
},
'xsd': 'http://www.w3.org/2001/XMLSchema#',
'children': {
'@reverse': 'rdfs:subClassOf'
}
},

[Larry Martell]

I tried changing the context to this:

'@id': 'http://elucidbio.com/CAPgraph/Thing',
'@type': 'rdfs:Class',
'name': 'Thing',
'children': [
{

'name': 'Observation',
'@id': 'http://elucidbio.com/CAPgraph/Observation',

'@type': '@owl:Class',

'rdfs:subClassOf': 'http://elucidbio.com/CAPgraph/Thing',
'children': [
{
'name': 'Reading',
'@id': 'http://elucidbio.com/CAPgraph/Observation/Reading',

'@type': '@owl:Class',

'rdfs:subClassOf':
'http://elucidbio.com/CAPgraph/Observation'
},
{
'name': 'Finding',
'@id': 'http://elucidbio.com/CAPgraph/Observation/Finding',

'@type': '@owl:Class',

'rdfs:subClassOf':
'http://elucidbio.com/CAPgraph/Observation'
},

]
},
],

But there was no change - we still got just a finding that was not a
subclass of observation and there was no observation class.

On Tue, Jun 21, 2016 at 11:02 AM, Evren Sirin <ev...@complexible.com> wrote:

[Larry Martell]

I also tried using 'Observation/Finding' for the type (instead of just
Finding), and that also did not work. When I did that now I have 2 top
level entires for Finding, one referring to elucid:Finding and one
referring to http://elucidbio.com/CAPgraph/Observation/Finding.

What I am trying to achieve is that when I expand Thing I see
Observation and then when I expand that I see Reading and Finding.

[Zachary Whitley]

You have http://elucidbio.com/CAPgraph/Thing defined as an rdfs:class not owl:class but I can't say if you have other problems. It would really help me to help you if you could provide complete examples so that I can attempt to reproduce what you're doing. Complete files, complete Python scripts being run, how the data is being loaded, etc.

Without that I can only guess what the problem is.

Changing the URL to "Observation/Finding" simply creates a different identifier. There is no interpretation given to the path. It's just an opaque identifier.

[Larry Martell]

Originally everything was rdfs:class. Evren Sirin suggested changing
to owl:class, but I wasn't sure exactly where that had to be changed.
I just tried changing Thing to and owl:class but still no joy.

The reason I tried changing the @id to Observation/Finding was because
I was not sure if jsonld.expand was doing the correct thing or not. It
was returning '@type': [u'http://elucidbio.com/CAPgraph/Finding'] -
should it be returning that or this '@type':
[u'http://elucidbio.com/CAPgraph/Observation/Finding'] ? I thought
perhaps if I passed in Observation/Finding I would get the latter. And
in fact I did. But I still did not get the ultimate results I want.

I will see if I can put together a minimal example that shows what we
are doing.

[andrew....@bbmsc.com]

Good morning,
The method we are using has been successful at creating what I believe are referred to as "TBox assertions" in Stardog, or what I take to be "instances" (e.g., as one would say in Protege).  In fact we routinely build up close to 300,000 such instances and ability to relate them with a rich set of properties in a processing job we're using nightly, but for the one problem that non of the classes reflect our desired is-a hierarchy. Our queries are also very effective, as evidenced by other jobs we run nightly that routinely process them, at least insofar as queries with no reasoning.  The current question of how to subclass stems from our current need to add reasoning to our queries, which presumably require that the is-a hierarchy be manifest... hence the drive to understand how to effectively subclass.

Continuing to study the Stardog document, it seems we are not creating any "ABox" assertions - the "schema" - hoping or expecting that this is occurring implicitly when we add instances using the context definition.  Is this the problem, or does it shed light on what we are missing?

When we started, I expected we would need to to load the schema (the ABox assertions?) from an ontology.  There was an earlier thread some months ago on this list to determine how to load one, but at the time we seemed to succeed at the instances and had not yet required reasoning so we never answered how to do that completely.  May I ask: is use of the context, as Larry and Mary have described, sufficient to create the ABox, or is it presuming that the ABox was already created and it is just "referencing" it?  Or am I misreading the documentation that there may be something missing and that the key is simply writing the context correctly, and that if done the ABox will occur implicitly?

Thank you,
Andy

[Zachary Whitley]

I believe you have the terms ABox and TBox flipped. T is for Terms and A is for Assertions. (Terminological and Assertional). Your TBox is your dictionary and Abox is your novel. It's a nice metaphor because they're both books with a bunch of words just like your TBox and your ABox are both just a box with a bunch of triples.

I think there might be a little confusion about what a "context" is. The context here is the JSON-LD context section that maps your normal JSON structure to triples that will allow a json-ld engine to extract triple and eventually load them into your database. The JSON-LD context does not involve Stardog but it would need to be correct to generate the triples you expect from the json-ld processor. The term "context" is also sometimes used to refer to what otherwise would be referred to as a named graph.

Larry contacted me with a complete example that I made a couple of minor corrections to that I believe will have you headed in the right direction.

[andrew....@bbmsc.com]

Thank you Zachary.  We have now successfully created the subclass hierarchy, and mapped properties.  In retrospect, thane changes were not large, but significant, including representing both the classes well as properties as indicated in these interactions, and also, loading the context itself rather than only using it when instances were added.  Zachary, we do thank you very much for hanging with us and the many helpful suggestions you made.

Andy and the team

[Zachary Whitley]

I'm glad that I could help and that you were able to achieve the results that you were looking for. In order to ensure your future success I would advise that you consider modifying your current work flow to either become more familiar with the JSON-LD syntax or move to a more friendly syntax like Turtle for which I've already expressed my personal preference. Ultimately it doesn't really matter as long as you are comfortable working with whatever syntax you ultimately choose. I believe that you will find that an investment now will pay large dividends in the future as you move to a more complex and expressive data model.