Skip to content

missing subClassOf edges #7

Open

Description

@dpwrussell

Hi,

I found this tool and started to make use of it to visualize my RDF database, which is great!

I don't quite understand what is happening with respect to subClassOf edges though. This example helps demonstrate.

The class hierarchy is:

  • Subject
    • User
    • Group

From reading your paper I think that subClassOf relations should be the second step in extracting data.

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX : <http://example.org/schema#>
PREFIX d: <http://example.org/data#>

INSERT DATA {

    :Subject rdf:type rdfs:Class .
    :User rdf:type rdfs:Class ;
          rdfs:subClassOf :Subject .
    :Group rdf:type rdfs:Class ;
           rdfs:subClassOf :Subject .

    d:bobGroup rdf:type :Group ;
               :name "Bob's Group" .

    d:jimGroup rdf:type :Group ;
               :name "Jim's Group" .

    d:tony rdf:type :User ;
            :name "Tony" ;
            :memberOf d:jimGroup .

    d:bob rdf:type :User ;
          :name "Bob Himself" ;
          :memberOf d:bobGroup .
}

However, all I see is this. The Subject class is never shown.

screen shot 2018-02-23 at 15 21 10

While I was debugging this, I accidentally added a triple to the d:tony User making it of type Subject as well as User. This doesn't really make sense, but it did cause the subClassOf edge to start appearing, so I'm pretty sure the triples are correct, but for some reason, the subClassOf does not get explored when I didn't have the below triple.

d:tony rdf:type :Subject .

Visualization with the Subject type:

screen shot 2018-02-23 at 15 37 22

Thanks

Activity

  1. marc92w commented on Mar 16, 2018

    @marc92w
    Member

    Hi,

    I think the behaviour you describe is intended and this is why:

    First of all I don't think your class "Subject" will be discovered in your example because there are no entities which are directly Subjects, only Users and Groups.

    This is the SPARQL query being used to extract the classes:

    SELECT DISTINCT ?class (count(?sub) AS ?instanceCount)
    WHERE { 
    	?sub a ?class.
    }
    GROUP BY ?class
    ORDER BY DESC(?instanceCount);
    

    As you see, there is no part to take instances of subclasses into account.

    Secondly, as LD-VOWL only works on the ABox, subclass relations are detected via the number of common instances in step 2 of the extraction:

    Speaking in sets you would expect this to be true:

    |User| < |Subject| and |User ∩ Subject| = |User|
    

    Every user is a subject but not every subject is a user, so the class User is a proper subset of class Subject which indicates User is a subclass of Subject

    But if you make one entity of type User also of type Subject you will end up with the following:

    |Subject| < |User| and  |User ∩ Subject| = |Subject| 
    

    Now the class Subject is a proper subset of User and this is why the arrow in your second screenshot goes into the wrong direction.

    For more information about the extraction process please have a look at our EKAW paper Extraction and Visualization of TBox Information from SPARQL Endpoints and if you have further questions feel free to ask.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions