Quite wrong. IS_JANITOR_OF will stick you into a boxed node ordinal. What you really want when modeling the world is to only capture the "semantic relationships" themselves. IS_A being a core semantic relationship. I am a janitor. He IS_A janitor. What is a janitor ? What properties does a janitor have ? Does a janitor always have those properties, no matter it's state ? Does a janitor that LIVES_AT the Seychelles Islands always have a pail and mop ?
When trying to model "the world", you must break down to the lowest of lows. And then use Types to clearly designate Property Reasonings. For instance, SWRC ontology says that Bioinformatics IS_A subtopic of KnowledgeWeb Applications. <p2:subTopic> <p1:ResearchTopic rdf:about=" https://wiki-sop.inria.fr/wiki/bin/view/Acacia/KnowledgeWeb#Bioinformatics";> <p2:isSubTopicOf rdf:resource=" https://wiki-sop.inria.fr/wiki/bin/view/Acacia/KnowledgeWeb#Applications"/> <p2:topicNumber rdf:datatype="http://www.w3.org/2001/XMLSchema#string";>2.7.3 </p2:topicNumber> </p1:ResearchTopic> </p2:subTopic> Great for them. But WHAT is Bioinformatics to the rest of "the world", generally ? Is it a FIELD_OF_STUDY as Freebase.com says ? Is it a STUDY_SUBJECT as other Vocabularies describe ? Is a FIELD_OF_STUDY the same as a STUDY_SUBJECT ? Or is it more proper and correct to say that a FIELD_OF_STUDY can be PART_OF a STUDY_SUBJECT ? Bioinformatics PART_OF Biology PART_OF Science ? I would say both and all. And there you would need many "semantic relationships", depending again on the domains' usage. In Freebase, we decided early on that the lowest of lows would be TOPICS. Some TOPICS could be given Types. A Janitor is a Type of Person. Oh Really ? No. Not always to some ! But all domains typically agree that a Janitor is a Profession. A Job_Type (TypeOfJob) that someone professes or agrees to WORK_AS for payment. And some folks might be enslaved to WORK_AS :) Existing Ontologies and Vocabularies (which are domain based, some wider than others) can help anyone trying to model "the world". However, be aware that many longtail domains, like Food Service, or Laser Etching, are simply not modeled, no one has touched those yet in building ontologies or vocabularies and henceforth, require community domain experts (the folks in those businesses or scientific or government communities) to help you think correctly within their domains, rather than how "the rest of world" would typically organize them. Organizing across *domains* with Types will require Namespaces for those domains, and in some cases, you will find that only a FEW Properties really apply to a specific Namespace. They are just simply NOT used by the rest of "the world". The very last part for you in modeling "the world" should be at a CONCEPT level. Like SKOS_CONCEPT. Only once you have seen the overlap of a CONCEPT across domains, can you then begin to give the answer, YES, when 2 or 3 domains ask, "Is this CONCEPT_OF "Janitor - a profession type where someone cleans" the SAME_AS ours and RELATED_TO the CONCEPT_OF "Maid" ? Proper "semantic relationships" have to allow flexibility across domains. Find some common overlapping Types and Topics across Domains, and then begin your experimentation there (and make sure you get a bit of History or Historical Types in there as well to account for Time Space associations - those always screw with my head personally, lol). You will soon begin to see that Domains are really like "Photoshop layers". -- -Thad http://www.freebase.com/view/en/thad_guidry _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
