{"id":771,"date":"2017-04-25T10:06:08","date_gmt":"2017-04-25T15:06:08","guid":{"rendered":"http:\/\/inova8.com\/bg_inova8.com\/?p=771"},"modified":"2019-04-23T02:31:05","modified_gmt":"2019-04-23T07:31:05","slug":"rdf2model-skos-to-prov-via-owl","status":"publish","type":"post","link":"https:\/\/inova8.com\/bg_inova8.com\/rdf2model-skos-to-prov-via-owl\/","title":{"rendered":"rdf2model: SKOS to PROV via OWL"},"content":{"rendered":"
\n
\n
\n

\nSKOS, the Simple Knowledge Organization System, offers an easy to understand schema for vocabularies and taxonomies. However modeling precision is lost when skos:semanticRelation predicates are introduced.<\/em>
\nCombining SKOS with RDFS\/OWL allows both the precision of owl:ObjectProperty to be combined with the flexibility of SKOS. However clarity is then lost as the number of core concepts (aka owl:Class) grow.
\n<\/em>Many models are not just documenting the \u2018state\u2019 of an entity. Instead they are often tracking the actions performed on entities by agents at locations. Thus aligning the core concepts to the Activity, Entity, Agent, and Location classes of the PROV ontology provides a generic upper-ontology within which to organize the model details.<\/em><\/p>\n

Vehicle Manufacturing Example<\/h1>\n

This examples captures information about vehicle manufacturing. Following<\/p>\n

    \n
  1. Manufacturers: the manufacturer of models of cars in various production lines sited at plants<\/li>\n
  2. Models: the models that the manufacturer produces<\/li>\n
  3. ProductionLines: the production lines set up to produce models of vehicles on behalf of a manufacturer<\/li>\n
  4. Plants: the plants that house the production lines<\/li>\n<\/ol>\n

    In addition there are different \u2018styles\u2019 of manufacturing that occur for various models and various sites:<\/p>\n

      \n
    1. Manufacturing: the use of a ProductionLine for a particular Model<\/li>\n<\/ol>\n

      SKOS Modeling<\/h1>\n

      If we follow a pure SKOS model we proceed as follows by creating a VehicleManufacturingScheme  skos:ConceptScheme<\/p>\n

      s:VehicleManufacturingScheme<\/p>\n

      rdf:type skos:ConceptScheme<\/p>\n

      .<\/p>\n

      Then we create skos:topConceptOf Manufacturer, Model, Plant, and Production as follows:<\/p>\n

       <\/p>\n

      s:Manufacturer<\/p>\n

      rdf:type owl:Class ;<\/p>\n

      rdfs:subClassOf skos:Concept ;<\/p>\n

      skos:topConceptOf s:VehicleManufacturingScheme<\/p>\n

      .<\/p>\n

      s:Model<\/p>\n

      rdf:type owl:Class ;<\/p>\n

      rdfs:subClassOf<\/u> skos:Concept ;<\/p>\n

      skos:topConceptOf s:VehicleManufacturingScheme<\/p>\n

      .<\/p>\n

      These top-level concepts are being created of type owl:Class and a subClassOf skos:Concept.  This is the pattern recommended in (Bechhofer, et al.)<\/p>\n

      Finally we can create skos:broader concepts as follows:<\/p>\n

      s:Ford<\/p>\n

      rdf:type s:Manufacturer ;<\/p>\n

      skos:broader s:Manufacturer ;<\/p>\n

      skos:inScheme s:VehicleManufacturingScheme<\/p>\n

      .<\/p>\n

      s:Fusion<\/p>\n

      rdf:type s:Model ;<\/p>\n

      skos:broader s:Model ;<\/p>\n

      skos:inScheme s:VehicleManufacturingScheme<\/p>\n

      .<\/p>\n

      The resultant SKOS taxonomy of the VehicleManufacturingScheme  skos:ConceptScheme then appears as follows:<\/p>\n

      \"\"<\/p>\n

      Figure 1: SKOS taxonomy<\/p>\n

      Why?<\/h2>\n

      By starting with a pure SKOS model we provide access to the underling concepts in a more accessible style for the less proficient user, as illustrated by the SKOS Taxonomy above. Yet we have not sacrificed the ontological precision of owl:Classes.<\/p>\n

      Thus we can ask questions about all concepts:<\/p>\n

      SELECT * WHERE<\/p>\n

      {<\/p>\n

             ?myConcepts rdfs:subClassOf+ skos:Concept .<\/p>\n

      }<\/p>\n

      Or we can get a list of anything broader than one of these concepts:<\/p>\n

      SELECT * WHERE<\/p>\n

      {<\/p>\n

             ?myBroaderConcepts skos:broader s:Model .<\/p>\n

      }<\/p>\n

      SKOS+OWL Modeling<\/h1>\n

      Although skos:semanticRelation allows one to link concepts together, this predicate is often too broad when trying to create an ontology that documents specific relations between specific types of concept.<\/p>\n

      In our VehicleManufacturingScheme we might want to know the following:<\/p>\n

        \n
      1. isManufacturedBy: which manufacturer manufactures a particular model<\/li>\n
      2. operatedBy: which manufacturer operates a particular production facility<\/li>\n
      3. performedAt: which plant is the location of a production facility<\/li>\n
      4. wasManufacturedAt: which production facility was used to manufacture a particular model<\/li>\n<\/ol>\n

        \"\"<\/p>\n

        Figure 2: SKOS+OWL model of Relations<\/p>\n

         <\/p>\n

        These predicates can be defined using RDFS as follows:<\/p>\n

        so:isManufacturerBy<\/p>\n

         rdf:type owl:ObjectProperty ;<\/p>\n

        rdfs:domain s:Model ;<\/p>\n

        rdfs:range s:Manufacturer ;<\/p>\n

        rdfs:subPropertyOf skos:semanticRelation<\/p>\n

        .<\/p>\n

        so:operatedBy<\/p>\n

        rdf:type owl:ObjectProperty ;<\/p>\n

        rdfs:domain s:Production ;<\/p>\n

        rdfs:range s:Manufacturer ;<\/p>\n

        rdfs:subPropertyOf skos:semanticRelation<\/p>\n

        .<\/p>\n

        Note that the definition of Model, Manufacturer etc. as subClassOf skos:Concept allows us to precisely define the domain and range.<\/p>\n

        s:Fusion<\/p>\n

        so:isManufacturerBy s:Ford ;<\/p>\n

        so:wasManufacturedAt s:Halewood-SmallVehicle ;<\/p>\n

        .<\/p>\n

        s:Dagenham-Truck<\/p>\n

        so:operatedBy s:Ford ;<\/p>\n

        so:performedAt s:Dagenham ;<\/p>\n

        .Thus we have used the flexibility of SKOS with the greater modeling precision of RDFS\/OWL.<\/p>\n

        Why?<\/h2>\n

        By building upon the SKOS model, one can ask an expansive question such as what concepts are semantically related to, say, the concept s:Fusion with a simple query:<\/p>\n

        SELECT * WHERE<\/p>\n

        {<\/p>\n

               s:Fusion  ?p ?y .<\/p>\n

               ?p rdfs:subPropertyOf* skos:semanticRelation<\/p>\n

        }<\/p>\n

        Yet with the same model we can ask a specific question about a relationship of a specific instance:<\/p>\n

        SELECT * WHERE<\/p>\n

        {<\/p>\n

               s:Camry so:isManufacturerBy   ?o .<\/p>\n

        }<\/p>\n

        SKOS+OWL+PROV Modeling<\/h1>\n

        One of the attractions of SKOS is that a taxonomy can grow organically. One of the problems of SKOS is that a taxonomy can grow organically!<\/p>\n

        As the taxonomy grows it can be useful to add another layer of structure beyond a catalog of concepts. Many models are not just documenting the \u2018state\u2019 of an entity. Instead they are often tracking the actions performed on entities by agents at locations. Thus aligning the core concepts to the Activity, Entity, Agent, and Location classes of the PROV ontology (Lebo, et al.) provides a generic upper-ontology within which to organize the model details.<\/p>\n

        \"\"<\/p>\n

        Figure 3: PROV model<\/p>\n

        Thus our VehicleManufacturingScheme has each core PROV concept:<\/p>\n

          \n
        1. Manufacturers: the Agents who manufacture models, and operate plants<\/li>\n
        2. Models: the Entities<\/li>\n
        3. ProductionLines: the Activities that produce Models on behalf of Manufacturers.<\/li>\n
        4. Plants: the Location at which Activities take place, and Agents and Entities are located.<\/li>\n<\/ol>\n

          \"\"<\/p>\n

          Figure 4: PROV Model<\/p>\n

           <\/p>\n

          s:Production<\/p>\n

          rdfs:subClassOf prov:Activity ;<\/p>\n

          .<\/p>\n

          s:Model<\/p>\n

          rdfs:subClassOf prov:Entity ;<\/p>\n

          .<\/p>\n

          s:Manufacturer<\/p>\n

          rdfs:subClassOf prov:Organization ;<\/p>\n

          .<\/p>\n

          s:Plant<\/p>\n

          rdfs:subClassOf prov:Location ;<\/p>\n

          .<\/p>\n

          Similarly we can cast our predicates into the same PROV model as follows:<\/p>\n

          so:isManufacturerBy<\/p>\n

          rdfs:subPropertyOf prov:wasAttributedTo ;<\/p>\n

          .<\/p>\n

          so:operatedBy<\/p>\n

          rdfs:subPropertyOf prov:wasAssociatedWith ;<\/p>\n

          .<\/p>\n

          so:performedAt<\/p>\n

          rdfs:subPropertyOf prov:atLocation ;<\/p>\n

          .<\/p>\n

          so:wasManufacturedAt<\/p>\n

          rdfs:subPropertyOf prov:wasGeneratedBy ;<\/p>\n

          .<\/p>\n

          Why?<\/h2>\n

          The PROV model is closer to the requirements of most enterprise models, that are trying to \u2018model the business\u2019, than a simple E-R model. The latter concentrates on capturing the attributes of an entity that record the current state of that entity. Often those attributes focus on documenting the process by which the entity gained its current state:<\/p>\n