SMW subobjects are proposed to be named like MW pagenames, i.e., scope:lang:type:topic-name Example: [[#enwp:property:^length]] is the name of a topic whose scope (or context, perhaps) is the english-wp; whose language defaults to that for its scope; whose topic type is "property" and whose name is ^length -- because of the 'hat' in its name, we know this property names occurrences of text (or numeric or mixed) strings. "length" property names similarly name pages &or subobjects. The subobject data structure is proposed to be the Dublin Core property set -- this leads to 28 properties that can be used to capture provenance for any named thing in the system. Examples: [[property:creator]] names a creator page (or subobject); note there is no 'hat' in its name. [[property:^creator]] is used for occurrences of (one of the) SKOS-note subproperties, i.e.,, this is a text property. And so forth for all the Dublin Core properties including [[property:type]] whose occurrences are singular common nouns defined in the Type namespace. The [[property:^type]] property names an occurrence of SKOS-related curator notes. RDF property names are the names of topics whose occurrences are text/page/subobject values &or iris, all values stored in iso-occurrence objects in the topic map as values of the (^obj, ^page, ^text, ^iri, ^en, ^mm, ^hz and others) smw-defined properties. Example: {{FULLPAGENAME}}#topicmap [[property:type]] [[type:iso-topicmap]] {{FULLPAGENAME}}#subject [[property:type]] [[type:iso-topic]] {{FULLPAGENAME}}#subject [[property:within]] [[{{FULLPAGENAME}}#topicmap]] {{FULLPAGENAME}}#property:length [[property:of]] [[{{FULLPAGENAME}}#subject]] {{FULLPAGENAME}}#property:length [[property:type]] [[type:iso-occurrence]] {{FULLPAGENAME}}#property:length [[property:^mm]] "numeric-millimeter-value" The "name" portion of a subobject name is required. If "type" is not supplied, it defaults to the "name" portion. Scope and language in a subobject name have default values. On 14.06.2012 16:19, jmcclure(a)hypergrove.com wrote: Nadja, wiki page represents for anything in WP, will not happen, imho ontology as seen at [[meta:wikitopics]] name, (name-) variant, association, context, etc class, property, datatype, etc because no class model is used to describe page content for these descriptions. indexes are what WP sorely lacks imho. can see that topic map class model is stored in SMW/RDF triples (in subobjects). application - outputs the topic maps as triples, query triples, etc. key point is that others can download WP topic maps & convert them into class model(s) appropriate to their application perhaps towards RDF->TM transforms.... hard to do..... I'm all about TM->RDF. wrote: pointer. Yes, I'd agree that 19788's ontology be closely reviewed for inclusion. 19788:2 standardizes the Dublin Core properties, the same I recommend for [[wikidata]] provenance data, the same slated for the [[wikidata]] ontology. But more to your point is that the entire ISO corpus would fit really well if it were viewed as a topic map whose topics and sub-topics can be referenced from [[wikidata]] artifacts such as property definitions." don't see why one would want to use topic maps. are after an identification (canonical: elements with the same URI are identified) know that some people call the triples themselves but why use a second word (namely graph) for triples? very trivial highly disconnected graph.). certain nodes of that graph to a topic nodes with an extra triple which says topic", i.e. something like (node, belongsto,thistopic) ) or modify the canonical identification map and the RDF graph will be a "topic map" or one has the case that the triples are that is for example resource URI then upon canonical identification these are "topic map" (with all "legs" pointing in one direction) or am I missing out something crucial? have no canonical information about the "internal structure" of topic and in some cases you would need to artificially impose this in retrospect onto of a society" , you have all the members and you would need some internal structure like a hierarchy each member with a hierarchy classification which is usually different for each member). For the RDF case the person who gave you could be given upon canonical identification. I.e. in principle the internal structure depends on your identification map but there is a canonical one. by choosing the topic to be the ressource and topic as a property and the topic which is connected with this "leg" as the object, but the more than one leg. Only if you would make all "legs" of a topic map into triples you would have something like a canonical assignment. I find these differences important. But may be I have overseen something or misunderstood scattered around in the internet so this is not so unprobable). >> I had this kind of discussion with people from deepa mehta http://www.deepamehta.de/ nobody there could convince me about the distinguished advantages of topic maps. discussion was because we discussed to what extend it would be possible to merge a student project we platform for visualizing RDF data called Mimirix http://www.daytar.de/art/MIMIRIX/) with deepa mehta, like for example one could use at least the backend, which has already a layout for access control really attacked the issue lease the carefully designed client. arguments for topic maps, as said I might have missed out something. adressability or direct access issues issue of the serialization I find. example the pregiven JSON structure of an JSONarray http://www.json.org/javadoc/org/json/JSONArray.html JSON-LD http://json-ld.org/spec/latest/json-ld-syntax/#sets-and-lists thats another topic. metadata you may want to read: http://www.azimuthproject.org/azimuth/show/Examples+of+semantic+web+applica… _______________________________________________ list >> Wikidata-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l scope