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, [email protected] wrote:
> Hello
Nadja,
>
> Topic maps do not populate a class model for whatever the
wiki page represents
> --- good luck getting agreement on a class model
for anything in WP, will not happen, imho
>
> TM itself has a small
ontology as seen at [[meta:wikitopics]]
> --- topic map, topic, type,
name, (name-) variant, association, context, etc
> --- note there is no
class, property, datatype, etc because no class model is used to
describe page content
>
> RDF describes class extents; WP has no need
for these descriptions.
> Topic maps describe subject indexes; subject
indexes are what WP sorely lacks imho.
> From [[meta:wikitopics]] you
can see that topic map class model is stored in SMW/RDF triples (in
subobjects).
> That said, [[wikidata]] is a fully-conforming RDF
application - outputs the topic maps as triples, query triples, etc.
> A
key point is that others can download WP topic maps & convert them into
class model(s) appropriate to their application
> You're oriented
perhaps towards RDF->TM transforms.... hard to do..... I'm all about
TM->RDF.
>
> regards - john
>
> On 14.06.2012 02:21, Nadja Kutz
wrote:
>
>> John McClure wrote:
>>
>> "Of course, thanks for the
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."
>>
>> Hello John
>>
>> Frankly speaking I
don't see why one would want to use topic maps.
>> That is RDF triples
are after an identification (canonical: elements with the same URI are
identified)
>> a labeled graph, here to be called "the" RDF graph. (I
know that some people call the triples themselves
>> "the" RDF graph,
but why use a second word (namely graph) for triples?
>> Triples are
very trivial highly disconnected graph.).
>> If I want to connect
certain nodes of that graph to a topic
>> I only need to supply these
nodes with an extra triple which says
>> ("this node belongs to this
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
>> already set out in "topics"
that is for example
>> if I have a set of triples with the same
resource URI then upon canonical identification these are
>> a kind of
"topic map" (with all "legs" pointing in one direction) or am I missing
out something crucial?
>>
>> However if you start with topics, you
have no canonical information about the "internal structure" of
>> a
topic and in some cases you would need to artificially impose this in
retrospect onto
>> the datastructure.
>> Like if your topic is "members
of a society" , you have all the members and you would need some
internal structure like a hierarchy
>> then you would need to supply
each member with a hierarchy classification
>> (i.e. with extra data,
which is usually different for each member). For the RDF case the person
who gave you
>> the triples could have made a choice of order which
could be given upon canonical identification. I.e. in principle the
>>
internal structure depends on your identification map but there is a
canonical one.
>> You can of course mimick a RDF triple with a topic map
by choosing the topic to be the ressource and
>> one "leg" of your
topic as a property and the topic which is connected with this "leg" as
the object, but the
>> choice of a leg is not canonical if there is
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
>> about topic maps (I read about this issue what I found
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/
>> because they used topic maps, but sofar
nobody there could convince me about the distinguished advantages of
topic maps.
>> But the discussion was sofar rather brief.
>> The
discussion was because we discussed to what extend it would be possible
to merge a student project we
>> had at HTW Berlin ( a collaboration
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
>> (the deepa mehta people told me that they haven't yet
really attacked the issue
>> of access control) or one could use at
lease the carefully designed client.
>>
>> May be you have other
arguments for topic maps, as said I might have missed out something.
>>
>> I understand that there are other issues like the speed of
adressability or direct access issues
>> but these are then rather an
issue of the serialization I find.
>>
>> So I didn't understand why for
example the pregiven JSON structure of an JSONarray
>>
http://www.json.org/javadoc/org/json/JSONArray.html
>> is not used in
JSON-LD
>>
http://json-ld.org/spec/latest/json-ld-syntax/#sets-and-lists
>> but
thats another topic.
>>
>> In the context of applications of ISO
metadata you may want to read:
>>
http://www.azimuthproject.org/azimuth/show/Examples+of+semantic+web+applications+and+environment
>>
_______________________________________________
>> Wikidata-l mailing
list
>> [email protected]
>>
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
scope _______________________________________________
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
