Unfortunately my SOLRSearch proposal was deemed ineligible [5] the
reason given that extensions require code review from WMF to deploy so
I hope yours is more successful.
-john
On 14.02.2013 07:14, Yaron
Koren wrote:
Hi everyone,
If you hadn't heard, the Wikimedia
Foundation has
Hi - Where can i see the rdfs/owl definition for o:Statement?
thanks - john
On 01.02.2013 12:09, Daniel Kinzler wrote:
On
01.02.2013 14:54, Nicholas Humfrey wrote:
While the reification
makes sense, we thought that it looked a bit too much like
rdf:Statement. w:Berlin s:Population
never mind - the previous note had a link. thanks
On 01.02.2013
16:30, jmccl...@hypergrove.com wrote:
Hi - Where can i see the
rdfs/owl definition for o:Statement?
thanks - john
On
01.02.2013 12:09, Daniel Kinzler wrote:
On 01.02.2013 14:54,
Nicholas Humfrey wrote:
While the
(if i knew the private email for Denny, I'd send this there)
Martynas, there is no mention here of XSD etc. because it is not
relevant on this level of discussion. For exporting the data we will
obviously use XSD datatypes. This is so obvious that I didn't think it
needed to be explicitly
The xsd:minInclusive, xsd:maxInclusive, xsd:minExclusive and
xsd:maxExclusive facets are absolute expressions not relative +/-
expressions, in order to accommodate fast queries. These four facets
permit specification of ranges with an unspecified median and ranges
with a specified mode,
I detect a need to characterize the range expression - most
important of which is whether the range is complete, or whether it
excludes (equal) tails on each end. XSD presumes a complete range is
being specified, not a subset, is the issue you're raising?
Could an
additional facet for
(Proposal 3, modified)
* value (xsd:double or xsd:decimal)
* unit
(a wikidata item)
* totalDigits (xsd:smallint)
* fractionDigits
(xsd:smallint)
* originalUnit (a wikidata item)
* originalUnitPrefix (a
wikidata item)
JMc: I rearranged the list a bit and suggested simpler
naming
JMc: Is not
I suspect what Martynas is driving at is that XMLS defines
**FACETS** for its datatypes - accepting those as a baseline, and then
extending them to your requirements, is a reasonable, community-oriented
procss. However, wrapping oneself in the flag of open development is
to me unresponsive to a
Using the dotted notation, XSD datatype facets such as below can be
specified easily as properties using a simple colon:
Property:
.anyType:equal - (sameAs equivaluent) redirect to page/object with
actual numeric value
Property: .anyType:ordered - a boolean property
Property:
totally agree - hopefully XSD facets provide a solid start to
meeting those concrete requrements - thanks.
On 19.12.2012 14:09,
Gregor Hagedorn wrote:
On 19 December 2012 20:01,
jmccl...@hypergrove.com wrote:
Hi Gregor - the root of the
misconception I likely have about significant
For me the question is how to name the precision information. Do not
the XSD facets totalDigits and fractionDigits work well enough? I
mean
.number:totalDigits contains a positive power of ten for
precision
.number:fractionDigits contains a negative power of ten for
precision
The use of
The NIST ontology defines 4 basic classes that are great:
_qudt:QuantityKind [11]_, _qudt:Quantity [12]_, _qudt:QuantityValue
[13]_, _qudt:Unit [14]_
but the properties set leaves me a bit
thirsty. Take Area as an example. I'd like to reference properties
named .ft2 and .m2 so that, for
Hi Max - why do you say now that Wikidata breaks the assumption
that pages store wikitext ?
Thanks
On 14.09.2012 08:06, Klein,Max
wrote:
Hello all,
I was wondering, now that Wikidata breaks
the assumption that pages store wikitext, has it been considered that
Wikidata concept pages
Hi Lydia - could you elaborate about this item in your excellent
report!.
* Added Type entity type, plus skeletons for its
associated Content, ContentHandler, ViewAction, EditAction and
UndoAction
I'm particularly keen to know how this facility relates to
fielding application-level
Thanks for the link. So Max's original question was whether a
content-type'd page containing (json-? xml-? rdf-?) -encoded data, can
have markup conforming to schema.org ontologies? Seems that if xml/rdf
is a supported content type then an opening does exist for such to be
implemented however
Your response doesn't direct me to a list of content types
(supported formats). But you know I'd suggest the answer to your
question wrt schema.org, is found in the published RDF [1]:
w:Berlin
s:Population Berlin:Statement1 .
Berlin:Statement1 rdf:type o:Statement
.
Note that we
Hi Nadja -
To my knowledge ISO has not published, nor is intending
to publish, instances of topic maps representing the content of their
numerous publications, using either their (ISO's) standard for Topic
Maps (ISO/IEC 13250), or any other ISO or non-ISO standard. Forgive me
if I ever gave
Hi Denny - your statement, that SNAKS can be related to RDF or
topic maps, is interesting to me, particularly your reference to topic
maps. I tend to interpret this as saying you believe SNAKS implements
the topic map data model, represented using RDF triples, that SNAKS is
informed by or
Luca,
You're right, and I apologize that I steered the discussion
from content classification back to an old wikidata data modelling
question -- SNAKS vs Topic Maps. Because I am ignorant about any ISO
classification standard whatsoever I thought the old bugaboo modelling
discussion was being
Nadja,
"Why is the topic map standard at http://www.topicmaps.org/standards/an unofficial topic map standard?" Links can be found to working technical committee reports, which are generally re-titled as "standards" once voted and accepted by ISO. These TC reports vary little from what is
No sir, that is not right. As I said there is no ISO classification
scheme of which I am aware. And I've said I no longer have interest in
the wikidata team using ISO Topic Maps - that is a dead issue since the
team declined to discuss it.
*At the time I wrote the emails you
referenced* I was
Hello,
The genesis of the legal question is the thread concerning
using ISO Topic Map precepts not SNAKs. Surely you know a number of
individuals on this forum feel that our challenge at that time was not
thoughtfully engaged. Instead we received replies focused on costs
associated with ISO
THIS EXTENSION IS OBSOLETE!
It has been replaced by core
functionality in the MediaWiki software (which was added in version
1.16.0).
[1] https://www.mediawiki.org/wiki/Extension:Oversight
On
17.08.2012 06:50, Lydia Pintscher wrote:
Hey folks :)
Here is
your fresh serving of
Hello,
For the current demo system, how many triple store
retrievals are being performed per Statement per page? Is this more or
less or the same as expected under the final design? Under the suggested
pure-transclusion approach, I believe the answer is zero since all
retrievals are performed
Hello Martynas,
Interesting to read about ESI at
http://en.wikipedia.org/wiki/Edge_Side_Includes.
I recall that a query
facility is intended for Phase 3, but I have no idea the kind of store.
I'd think that a quad-store is appropriate to storing provenance data in
mind for each triple. It'd
Dear all,
With regard to the whitepaper/demo Gregor asked for, if
there's some real interest expressed by the wikidata team in this,
that'd be good to hear. So far little/no comment has been offered about
the wikitopics approach or transclusion. It's hard to get excited about
investing my
.
On 13.06.2012 23:48, Nikola Smolenski wrote:
On 14/06/12
00:39, jmcclure@hypergrove.comwrote:
Transclusion is surely
fundamental to wiki application design. The [[wikidata]] proposal by
contrast is a client-server API, such things an artifact of the 20th
century. What is the point of it here? Ultimately
I strongly disagree with the demand to make this the only choice.
-
Gregor, I'm a bit confused -- are you talking about the transclusion
design approach in this statement? because, if so, I'd think there'd be
a number of infobox styles that can be selected by an author on the
wikidata
Gregor says
Or are you proposing to simply use the existing
template programming
with the only the difference that wikidata is the
only mediawiki where
the properties can be accessed within templates?
Much of my argument
assumes that you are looking for a non-template
based infobox
renderer, I
Hi Friedrich - IAANAA (I also am not an attorney)! and likely know
no more than yourself about the issues.
1.
http://en.wikipedia.org/wiki/Topic_Map [3]s gives links to iso/iec 13250
2. The 'community' includes developers who contractually/implicitly
guarantee the provenance of the
Hi James,
thanks for the pointer to [1].
1. The main use case
of Wikidata (a centralised, multi-lingual site that serves as a data
repository) is different from that of SMW (a data-enhanced MediaWiki)
OK, SMW installations can be centralized repositories (try DSMW) and
obviously can be
I do appreciate that Denny Jeroen and Markus cross-fertilize. But
the money is flowing now towards _REWRITING SMW FROM SCRATCH_, which
worries me as I am fairly sure there will be no good migration path at
the inevitable time SMW support is terminated. The fact that one (is
said) to be only for
Gerard,
Sure there's plenty of people who can build a prototype
application of this sort -- most people pay mortgages though so it'd be
nice (if not required) to get compensated for such work, as you the
wikidata team are.
re the wikidata excuse: it's wise to change one's
heading before
I base my belief that [[wikitopics]] is operationally faster on a
basic difference between the two designs, as I think the wikipedias will
operate faster if they merely transclude infoboxes of their choice, at
their own speed, from the wikidata central repository.
Transclusion is
surely
I don't understand why it's so unlikely, Lydia. ANY educational
article (science, math, engineering) can have graphics whose underlying
data is not language-sensitve. How about timelines on a bio article --
that's anothr example. Or a map within a place article? Or financial
data within a
sorry daniel for saying that, lydia is right on.
collegially yours
- john
On 13.06.2012 16:15, Lydia Pintscher wrote:
On Wed, Jun 13,
2012 at 7:41 PM, jmccl...@hypergrove.com wrote:
Daniel - this
distinction between facts vs claims -- is happy bullshit merely meant to
calm the masses.
Hi Lydia,
Specifically I'm keen to understand that
*
[[wikidata]] is committed to build-out smw for provenance data (and
ContentHandler, per SRF formats);
* [[wikidata]] is establishing a base
grammar for everyone to share via Type, Tag, Subject and other
namespaces;
* [[wikidata]]'s
1. as mentioned several times, a standard for us to be considered
must be free. Free as in Everyone can get it without having to pay or
register for
it. I can give it to anyone legally without any
restrictions. Free of patents. Free as in W3C.
2. I have taken another
look at your page, and
Hi all!
Am a bit mystified here! about the radio-silence to this
thread or, for that matter, to the [[meta:wikitopics]] [1] document
itself.
From wikipedia: [2]
REINVENTING THE SQUARE WHEEL is the
practice of unnecessarily engineering artifacts that provide
functionality already provided
Dear all,
Comments are welcomed about a page I just posted which
posits the use of the topic map metamodel (TMM) in the wikidata project.
I'll do my best to respond, but frankly my focus these days is on more
mundane topics like simple survival.
Cheers - john
Belltower Wikis
40 matches
Mail list logo
