wrote:
On Thu, Apr 23, 2015 at 10:16 AM, Edward Betts edw...@4angle.com wrote:
Thad Guidry thadgui...@gmail.com wrote:
I helped with the Lighthouses schema in Freebase.
Some of which is based on List of Lights (NGA) USA.
I have DB conversion data for the PDFs...just never got around
BTW, the Freebase ingestion later this summer should help fill a few of
those holes in population and other statistics. We had US Census, World
Bank, and UN Data as our primary data sources for any /statistics/ of a
City/Town/Village. Here's Houston -
Nice work Haklae and team !
And thanks for making this investment and sharing it publicly. This will
help everyone involved as migration progresses forward.
Thanks again,
Thad
+ThadGuidry https://www.google.com/+ThadGuidry
On Wed, Apr 8, 2015 at 8:03 AM, Kim Haklae haklae...@gmail.com wrote:
:
Citiranje Thad Guidry thadgui...@gmail.com:
I think a simple naming convention would suffice (and clean up the
existing
ones): blah ID such as for example:
CANTIC ID
Freebase ID
Munzinger IBA ID
NLP ID
dmoz ID
Oxford Biography Index ID
SELIBR ID
How would you name ISBN
Re-reading...
Erik,
I think you mean that the display itself for instance on this page:
https://www.wikidata.org/wiki/Q42
would be more useful if all Identifiers were pushed down to the bottom half
or different section, for instance, and keeping descriptor properties on
the upper half ? (instead
Why do you have to get lost in them ?
Most already have the phrase ID or Identifier in their naming
convention. So perhaps a better approach would be to standardize the
naming convention used for External Identifiers and make it a best practice
and golden rule during property creation and
I helped with the Lighthouses schema in Freebase.
Some of which is based on List of Lights (NGA) USA.
I have DB conversion data for the PDFs...just never got around to loading
them all in.
Let me know if I can help.
Thad
+ThadGuidry https://www.google.com/+ThadGuidry
On Tue, Mar 10, 2015 at
Think... BIGGER.
Jo has the right idea... Linked Data.
It sounds to me like the right way forward for domain specific interest
data (like OSM) ...is,
Instead of 1 source of data (Wikidata)...and throwing domain specific
interest data into Wikidata (not all data needs to live inside it).
Just
Back to the original discussion...and summary...
Anyways, thanks to all for summing up the current state of the Properties
on properties which is the 1st step for the Rules enforcement and that
will offer similar capabilities that Freebase had with Incompatible Types.
Also I feel more
Freebase originally had 2 modes. View and Edit. And then changed to only
an Edit mode (where some properties were no longer hidden)
Wikidata as far as I know only has Edit (All properties are shown in the UI)
Derived properties might work, but only in a View mode. Or only if
Derived
https://www.wikidata.org/wiki/Property:P279 aka the superclass ...
seems to have an equivalent property that refers to
http://www.w3.org/2000/01/rdf-schema#subClassOf ???
dunno.
Thad
+ThadGuidry https://www.google.com/+ThadGuidry
___
Wikidata-l
So Lydia,
Your saying that if I see https://www.wikidata.org/wiki/Q18614948 as a
property on another Property... then that is similar to the Freebase
disambiguating flag ?
In Freebase, we have just one flag but that is not the case here,
correct ? Wikidata has (or might have) several such
Thanks for explaining Markus.
The advantage of avoiding equivalentProperty in favour of
subPropertyOfExternalProperty
(and similarly for classes) is also that our definition can be more
specific than the one used for the external property/class. So we can
relate our data to multiple external
Markus,
Devils in the details. =)
You used the English word associated. That's great. Then I would
propose to expand the definition of P17 just a bit to add that.
P17 Country - sovereign state of this item ... to ... sovereign state
ASSOCIATED with this item
Then you save the world. =)
Freebase has mutexes that store incompatible type information.
For instance, in Wikidata I noticed on the U2 band topic, that they have
statements of:
P17 Country - sovereign state of this item.
P740 Location of formation - location where a group or organization was
formed.
In Freebase we have
On Thu, Jan 8, 2015 at 12:17 PM, Federico Leva (Nemo) nemow...@gmail.com
wrote:
Thad Guidry, 08/01/2015 18:58:
Unless the P17 Country property had an expanded definition of sovereign
state (or originating sovereign state) of this item
That's more like P27. Both are rather flexible though
Hi Marcus!
Yes, you and I are on the same page. Yes, I know about the Property-first
view of WIkidata. No quibbles. But there is still an issue with
Assumptions for Country P17 being used for an instance of Band...so let's
clarify this...
So, I guess things are fuzzy, because I do not jump to
Hi Lydia,
It's more than that. I can get labels just fine with props=labels
Ideally there were be a Number 3 a reconcile service, or an API that
can be USED as a reconcile service.
Given a search string of Paris, let's say...
1. Return some disambiguating properties and their labels and
Yes I did try wbsearchentities, and your right, it returns more via a
search operator.
The problem with wbsearchentities is that it is limited and cannot
additionally pipe output for the claims information (ideally important
claims only, disambiguating claims/properties)
Thad
+ThadGuidry
19 matches
Mail list logo
