Markus- Congrats because SMW 1.7 is a real bellringer - can't wait to upgrade. I was thinking that "named subobjects" can parallel wiki pagenames, [[#interwiki:en:ns:pgnm]]. Some namespaces would be nice to reserve would be #Dublin Core:, #OWL:, #SKOS:, #Topic Map: etc and their information elements easily defined. And should SF be able to associate forms with subobject namespaces (and categories), it seems a page can maintain a virtual wiki. What a coup!
Topic maps distinguish type, subjects, scopes, names, associations & occurrences - an ISO model of an index at the back of any reference book. A minimalist implementation is to associate subjects, like categories, in a page's #DublinCore:Subject property. Subjects can be SKOS objects defined in Subject: namespace, where eg the Library of Congress Subject Headings are defined. Markup is just [[Subject:subjectname]] on any page or within any subobject. [By within, I mean a #^text property for content that's copied into a page should it be "moved" from subobject to page -- this text can contain category and subject markup too]. To be fully wiki, {{pgnm#DublinCore}} might transclude the same material as {{pgnm/DublinCore}} using this #^text property.
Their idea of "type" in xtm:scope:xtm:type:xtm:name maps to wiki namespaces more naturally than categories can. Today, categories confuse plural lists of things with singular types of thing, causing a few practical problems. Singular nouns seem best defined in Type namespace with instances located in an appropriately named MW namespace or MW namespace alias. Note, MW can handle 64K namespaces, maybe for a seriously good dictionary of common nouns and noun-phrases like Wiktionary?
A few grammatical ideas. A tilde unary operator that does a "like" page or object selection, and filters for categories and subjects that apply to pages & subobjects alike, seems valuable. A magic word {{ANAMESPACE}} ("A" prefix = "A-box") might be nice too to identify a subobject's namespace.
page filters [[~{{FULLPAGENAME}}#DublinCore:]] [[Category:Active]][[Subject:LCSH Science]] subobject filters [[~{{FULLPAGENAME}}#DublinCore:]] [[#Category:Active]][[#Subject:LCSH Science]] both filters [[{{NAMESPACE}}:+]] [[Category:Active ]][[Subject:LCSH Science]] [[#Category:Active]][[#Subject:LCSH Science]]
One alternative subobject naming is {{FULLPAGENAME}}#{{FULLPAGENAME}} which is a Dublin Core object ie [{{FULLPAGENAME}}#{{FULLPAGENAME}}] |?Contributor|?Coverage...|?Subject|?Title|?Type
So [[Subject:pgnm]] markup for a page can be stored in the Subject property in a {{FPN#FPN}} or {{FPN#DublinCore}} object. Another approach is that mediawiki build a Category-like mechanism, with its own set of tables and indexes, for Subjects. This may boil down to which part of the wiki stack a [[Subject:pgnm]] tag best processed. I think a [[Subject:pgnm]] could be a useful addition to wiki markup so I hope that doesnt get obscured. Wikidata may want to incorporate ideas concerning Topic Maps - strategically it's possibly an easy big win, so I'll bother them too.
-----Original Message----- From: Markus Krötzsch [mailto:markus@semantic-mediawiki.org] Sent: Wednesday, March 21, 2012 7:43 AM To: jmcclure@hypergrove.com Subject: Re: [Wikitech-l] Topic Maps
On 21/03/12 13:06, John McClure wrote:
(1) official ISO versions are purchaseable while unofficial
versions are
foss.
Ok, that's a pity. A standard that nobody can read is not so helpful ... We already had this issue with other ISO standards before. In the end, people just ignore them because they do not get to them.
(2) there is a TMAPI which I think is conceptual not a
software library. Use
XML parser.
I was more thinking of a library to represent and manipulate topic maps in a program. Parsing it is one thing, but representing TMs as a kind of DOM tree (that you would get from XML) would not be so great I guess.
(3) Drupal has an extension now. There are a few others. (4) again, there's a QL but it's far more SQL - check it
with XTM for data
structures.
Ok, so there is a standard mapping from TM to RDB that allows SQL to be used for querying?
Personally, topic maps should be implemented in WP using
SMW's subobjects.
Ah, so I suppose you are viewing TMs more as a kind of conceptual model than as a concrete standard with a fixed syntax/semantics. Fair enough.
Regards
Markus
-----Original Message----- From: Markus Krötzsch [mailto:markus@semantic-mediawiki.org] Sent: Wednesday, March 21, 2012 3:28 AM To: jmcclure@hypergrove.com Subject: Re: [Wikitech-l] Topic Maps
[Off-list, maybe off-topic too ;-)]
Hi John,
I would actually like to learn a bit more about topic maps.
Could you
maybe help me to answer some of the following questions?
(1) Where can I see the official standard? All the documents that I found start by saying that they are not the ISO standard.
Where is the
official spec?
(2) Which software libraries support topic maps? (parsing,
API, etc.)
For which other tasks is there support in existing software
(authoring
tools? database systems? reasoners?).
(3) What are the major users of topic maps today? Where are
they used?
(4) How does one query information that is stored in topic maps? (In other words: which kinds of data access are supported?)
Thanks,
Markus
On 21/03/12 00:53, John McClure wrote:
Adding Topic Maps to MW base software could be a winner --
it can generate a
wiki-site map (some think WP needs one!); it can be used to
corelate the
contents of documents loaded into a wiki (like conference
proceedings) with
a wiki's topic map; and would make a cool tool for any page
in a wiki, most
clearly on a user page. It's perhaps a smart strategic move
- ISO 82250
Topic Maps are the fruit of SGML/Hytime n-ary models that
'lost' to RDF
triples back when. Being a superset of RDF, TMs can type
associations
between articles while capturing all infobox data.
Topic maps may be a compelling FUNCTIONAL upgrade for MW as
it captures
subjects of an article for the first time. Given topic-map
to RDF transforms
amid continuing W3 research, this could be enough for the
semantic world. By
adopting say the Lib of Congress' Subject Headings, a wiki
like Wikipedia
could play an important role in the semantic web. The
current situation with
Wikipedia is that it's hard to have a large library of
information without a
subject catalogue... right now, wikis have an author
catalogue sort of, fine
for smaller hadcrafted wikis but doesn't scale well for many.
Since other platforms now have maturing topic map extensions
I'm worried the
impact on wikis not to have that technology.
John McClure
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l