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+applicat...
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+applicat...
_______________________________________________
Wikidata-l mailing
list
Wikidata-l@lists.wikimedia.org
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@hypergrove.com 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+applicat...
_______________________________________________
Wikidata-l mailing
list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
scope
A template for infoboxes that could be produced by [[wikidata]] is discussed. As a preliminary, I'd propose that a new SRF be established, ie {{#ask: ...|format=infobox |language=en}} which creates/formats the "plain vanilla" infobox that's been discussed. An Infobox SRF looks up language-specified labels if not provided on the #ask call. Under [[wikitopics]] the triples accessed could be
Property:Length#Self [[property:type]] [[Type:Property]] Property:Length#Title [[property:type]] [[Type:iso-name]] Property:Length#Title [[property:of]] [[Property:Length#Self]] Property:Length#Title [[property:^en]] "english title" Property:Length#Title [[property:^de]] "german title" Property:Length#Abbrev [[property:type]] [[Type:iso-variant]] Property:Length#Abbrev [[property:of]] [[Property:Length#Title]] Property:Length#Abbrev [[property:^en]] "english variant" Property:Length#Abbrev [[property:^de]] "german variant" Property:Length#Informal [[property:type]] [[Type:iso-scope]] Property:Length#Informal [[property:for]] [[Property:Length#Abbrev]] Property:Length#Informal [[property:^en]] "english scope-name" Property:Length#Informal [[property:^de]] "german scope-name"
An Infobox is composed of Tiers, any tier can have an image, link, text, transclusion, template, SRF or topic output; plus a caption & style information. Following is a template call that is the content of [[Infobox:Some topic]] on a wikidata host. This page can then be cached/transcluded.
{{Wikidata Infobox |style = css |class = class-name |tier00 = content above the infobox, uses template:Tier. |tier01 = {{Tier|type=text |caption=a caption |text=some text |style=css|capstyle=css}} |tier02 = {{Tier|type=text |caption=a caption |page=pgnm |style=css|capstyle=css}} |tier03 = {{Tier|type=text |caption=a caption |text={{template-name}} |style=css|capstyle=css}} |tier04 = {{Tier|type=text |caption=a caption |text={{#ask:...}} |style=css|capstyle=css}} |tier05 = {{Tier|type=link |caption=a caption |iri=some iri |text=link text |style=css|capstyle=css}} |tier06 = {{Tier|type=link |caption=a caption |page=pgnm |text=link text |style=css|capstyle=css}} |tier07 = {{Tier|type=image |caption=a caption |image=pagename |style=css|capstyle=css}} |tier08 = {{Tier|type=topic |caption=a caption |topic=...tbd... |style=css|capstyle=css}} |tier99 = content below the infobox, using template:Tier }}
The template above doesnt (yet) address (topic) labels or values - see tier08.
Thanks - john