Re: [Dbpedia-discussion] Mapping-based Property errors

[Dimitris Kontokostas]

Hi Vladimir,

On Mon, Sep 7, 2015 at 5:56 PM, Vladimir Alexiev <
vladimir.alex...@ontotext.com> wrote:

> I'd like to point everyone's attention to:
> http://wiki.dbpedia.org/Downloads2015-04 Mapping-based Properties (errors)
> "Errors detected in the mapping based properties. At the moment the errors
> are limited to ranges that are disjoint with the property definition".
> - In many cases this reflects inflated expectations by ontology authors as
> to what Wikipedia editors put in fields.
>

Yes, this remark is correct, wrong modeling can lead to wrong errors :)


> - But the ERRORS file itself seems to be old (doesn’t correspond to
> current dbpedia data).
>

I don't get the old part here. All static versions are based on older
versions of wikipedia.
But, all these datasets originate from the same wikipedia dumps and the
errors are generated by processing the mapping-based-properties file.
The mapping-based-properties file is then split to two datasets, correct /
errors and only correct is loaded in the endpoint, the error dataset is
provided for completeness.


>
> E.g. see
> http://downloads.dbpedia.org/preview.php?file=2015-04_sl_core-i18n_sl_en_sl_mappingbased-properties-errors-unredirected_en.ttl.bz2
> :
> Let's prefixize it by using these prefixes http://prefix.cc/dbr,dbo.ttl
> and "riot --out=turtle" and take a look:
>
> ---
>
> dbr:Alfred_Hitchcock  dbo:almaMater  dbr:Enfield_Town .
> # ERRORS file is old, dbpedia has dbr:St_Ignatius'_College,
> dbr:Salesian_College_(London)
>

This is the data that the extraction framework found
https://en.wikipedia.org/w/index.php?title=Alfred_Hitchcock=edit=645850279
and based on the ontology modeling we moved   dbr:Enfield_Town to the
errors dataset


> dbr:Amitabh_Bachchan  dbo:almaMater  dbr:Nainital .
> # ERRORS file is old, dbpedia has "dbp:almaMater dbr:Nainital" but no
> "dbo:almaMater dbr:Nainital". How is the latter filtered?
>

we do the filtering based on the dbo namespace only, dbp has no axioms that
we can reuse


> dbr:Alois_Alzheimer  dbo:institution  dbr:Frankfurt .
> # Institute for the Insane and Epileptic ("Irrenschloss"), [[Frankfurt am
> Main]]. Here the literal is right, but dbo:institution is an objectProperty
> so it extracts the link (wrong)
>

we can change the type of dbo:institution to make it comply to more values


> dbr:Alberto_Giacometti dbo:training  dbr:Geneva .
> # The School of Fine Arts, [[Geneva]]: same reason
>
> dbr:A._E._Housman  dbo:almaMater  dbr:Oxford .
>
> dbr:British_Army  dbo:country  dbr:Elizabeth_II .
> # allegiance= [[Elizabeth II]]. So the map dbp:allegiance -> dbo:country
> is wrong
>
> dbr:Cardiff  dbo:leaderName  dbr:Wales .
>
> dbr:Cheers  dbo:location  dbr:Paramount_Pictures .
> # "Cheers" is "shot on location" in these studios.
> # dbr:Paramount_Pictures is dbo:Company, dbo:Agent, dbo:Organisation but
> not place (the only
> # Library is the only Org that's also a Place:
> Library
> dbr:Chernobyl  dbo:leaderName  dbr:Chernobyl_Exclusion_Zone .
> # [[Chernobyl Exclusion Zone#Administration|State Agency of Ukraine on the
> Exclusion Zone Management]]. There's no article about that admin agency,
> only a section... Nobody is to blame here.
>
> dbr:Carlos_Valderrama__12 dbo:team  dbr:Colombia .
> dbr:Carlos_Valderrama dbo:team  dbr:Colombia .
> # ERRORS file is old, live.dbpedia has dbo:team
> dbr:Colombia_national_football_team
> # https://en.wikipedia.org/w/index.php?title=Carlos_Valderrama=edit
> # "IntermediateNodeMapping | nodeClass = CareerStation" maps
> clubs1...clubs15.
> # But "PropertyMapping | templateProperty" maps only to clubs10. So these
> two are not in dbo:team (fixed):
> #  clubs12 [[Colorado Rapids]]
> #  clubs10 [[Miami Fusion]]
> # They are mapped at
> http://mappings.dbpedia.org/index.php?title=Mapping_en:Infobox_football_biography=edit
>
>
>
> --
> ___
> Dbpedia-discussion mailing list
> Dbpedia-discussion@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>



-- 
Kontokostas Dimitris
--
___
Dbpedia-discussion mailing list
Dbpedia-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion

Re: [Dbpedia-discussion] Area code madness in DBPedia

[Kingsley Idehen]

On 9/8/15 7:19 AM, Rinke Hoekstra wrote:
> Hi all,
>
> At the VU University Amsterdam, we're teaching various courses on the
> Semantic Web in which (understandably) DBPedia plays an important role.
>
> Over the past year's we have carefully groomed and curated a
> collection of example SPARQL queries against DBPedia. These queries
> revolve around cities with the "020" area code. 
>
> To my surprise, these queries suddenly stopped working. Apparently
> because there has been a new release of DBPedia in which this was changed.
>
> ... however... it turns out that they work sometimes but do not work
> at other times... madness! ;-)
>
> A bit of background:
>
> The examples use the  property
> (i.e. a curated property), and assume the area codes are represented
> as string literals, e.g. "020", sometimes with an erroneous language tag.
>
> It now seems that in some versions of the DBPedia endpoint, the
> property  has been demoted to
>  (i.e. a non-curated version) in
> *all* data: there is no place name with a dbpedia-owl:areaCode
> property. Even though the areaCode property is still defined in the
> ontology (at least, that's what I see when I point my browser at it).
>
> In addition to that (and much much worse), in some versions of the
> DBPedia endpoint, area codes are represented as *integers*, but are
> syntactically still presented as the value they had as strings. E.g.
> the area code for Amsterdam is represented as 020 rather than "020".
> Needless to say that 020 as an integer is equal to 20 hm
> that's not what we want Area codes simply are not integers, they are
> strings, because the actual digits matter. 
>
> (also, application developers should be able to rely on relative
> stability of statements that use the dbpedia ontology namespace, also,
> the ontology should only change monotonously: only add classes,
> properties etc., don't remove them!)
>
> In short:
> A couple of months ago, the area codes were represented as language
> tagged strings using the dbpedia-owl:areaCode property
>
> Yesterday morning at approx. 10 am, the area codes were represented as
> integers using the dbpedia-prop:areaCode property
>
> Yesterday evening, at approx. 10 pm, the area codes were represented
> as language tagged strings using the dbpedia-owl:areaCode property
>
> Today, at approx. 1 pm, the area codes were represented as integers
> using the dbpedia-prop:areaCode property
>
> ... 
>
> It would be exceedingly nice if this could be fixed. Perhaps it has
> something to do with load balancing and different stores not being
> synchronized properly?
>
> -Rinke
>
> PS ... area codes may be strings... but they don't have to be
> language-tagged ;-)


Rinke,

Do you have a SPARQL query URL that demonstrates the kind of volatility
that you are describing?

-- 
Regards,

Kingsley Idehen   
Founder & CEO 
OpenLink Software 
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this



smime.p7s
Description: S/MIME Cryptographic Signature
--
___
Dbpedia-discussion mailing list
Dbpedia-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion

[Dbpedia-discussion] Area code madness in DBPedia

[Rinke Hoekstra]

Hi all,

At the VU University Amsterdam, we're teaching various courses on the
Semantic Web in which (understandably) DBPedia plays an important role.

Over the past year's we have carefully groomed and curated a collection of
example SPARQL queries against DBPedia. These queries revolve around cities
with the "020" area code.

To my surprise, these queries suddenly stopped working. Apparently because
there has been a new release of DBPedia in which this was changed.

... however... it turns out that they work sometimes but do not work at
other times... madness! ;-)

A bit of background:

The examples use the  property (i.e.
a curated property), and assume the area codes are represented as string
literals, e.g. "020", sometimes with an erroneous language tag.

It now seems that in some versions of the DBPedia endpoint, the property <
http://dbpedia.org/ontology/areaCode> has been demoted to <
http://dbpedia.org/property/areaCode> (i.e. a non-curated version) in *all*
data: there is no place name with a dbpedia-owl:areaCode property. Even
though the areaCode property is still defined in the ontology (at least,
that's what I see when I point my browser at it).

In addition to that (and much much worse), in some versions of the DBPedia
endpoint, area codes are represented as *integers*, but are syntactically
still presented as the value they had as strings. E.g. the area code for
Amsterdam is represented as 020 rather than "020". Needless to say that 020
as an integer is equal to 20 hm that's not what we want Area codes
simply are not integers, they are strings, because the actual digits
matter.

(also, application developers should be able to rely on relative stability
of statements that use the dbpedia ontology namespace, also, the ontology
should only change monotonously: only add classes, properties etc., don't
remove them!)

In short:
A couple of months ago, the area codes were represented as language tagged
strings using the dbpedia-owl:areaCode property

Yesterday morning at approx. 10 am, the area codes were represented as
integers using the dbpedia-prop:areaCode property

Yesterday evening, at approx. 10 pm, the area codes were represented as
language tagged strings using the dbpedia-owl:areaCode property

Today, at approx. 1 pm, the area codes were represented as integers using
the dbpedia-prop:areaCode property

...

It would be exceedingly nice if this could be fixed. Perhaps it has
something to do with load balancing and different stores not being
synchronized properly?

-Rinke

PS ... area codes may be strings... but they don't have to be
language-tagged ;-)
--
___
Dbpedia-discussion mailing list
Dbpedia-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion

Re: [Dbpedia-discussion] [Spam] Re: Area code madness in DBPedia

[Markus Kroetzsch]

On 08.09.2015 22:08, Paul Houle wrote:
> Note it is a general Liked Data problem that if you put together data
> from the wild you will wind up with different ways of writing literals
> as well as URIs that compete with literals.
>
> SPARQL,  as it is today,  produces the same answers you would get from a
> relational database if the Unique Name Assumption applies.  This is just
> as true for literals as it is for URIs.  Some examples
>
> * it is "reasonable" for people to write "8"^^xsd:byte,  and otherwise
> use many different data types when they want to express an integer.
> * say you are aggregating data into a vocabulary like foaf,  once again
> there are multiple ways that people will encode email addresses no
> matter what you tell them,  for instance as a literal string is
> reasonable,  but also a mailto: URI is reasoanble.
>
> One of the missing links in RDF tooling is something to normalize these
> things.  In the wider world,  the U.N.A. definitely does not hold,  but
> if you can enforce it in an area,  people know how to write SPARQL
> queries and interpret the results -- otherwise it is a problem for a PhD
> thesis.

Actually, the part for datatypes like byte and int is solved, see 
http://www.w3.org/TR/sparql11-entailment/#canonicalRep. It is not 
required by the standard that all tools implement this, and thus some don't.

Further entailment regimes of SPARQL 1.1 do not require a UNA either 
(since we don't have it in RDF(S) or OWL). Mapping string emails to 
mailto: URIs is another issue, of course.

Markus

>
> On Tue, Sep 8, 2015 at 2:03 PM, Rinke Hoekstra  > wrote:
>
> Hi Kingsley and Dimitris,
>
> Thanks again for your replies.
>
> I suggest we leave it for now. I really wasn't asking you to solve
> my problem... it's trivial, I can come up with other equally
> relevant SPARQL examples if needed. I am well aware of the
> instability of the DBPedia property namespace, and only resorted to
> it because my normal route appeared to be blocked.
>
> I apologize if my initial email was overly polemic.
>
> I was just as surprised as you are that DBPedia behaved differently
> at different times: it shouldn't happen. As Kingsley says, the data
> is relatively stable. That's the reason I sent the email: just in
> case there was some weird bug on your end. I cannot provide proof
> other than what I told you.
>
> For now, a query on: ?city  dbpedia-owl:areaCode "020"^^xsd:string
> seems to work, so I'm good to go. I'll keep a backup of the
> DBPedia-property namespace-based solution just in case the temporal
> flux appears again. (and of course, I'll notify you immediately once
> that happens, with a full report)
>
> -Rinke
>
>
>
> On Tue, Sep 8, 2015 at 6:12 PM Kingsley Idehen
> > wrote:
>
> On 9/8/15 11:13 AM, Rinke Hoekstra wrote:
>> Hi Kingsley,
>>
>> Thanks for your help. I am aware that the two queries use a
>> different predicate; that's part of the problem.
>
> You should stick with the predicate that provides the solution
> you seek.
>
>
>>
>> The issue is that depending on the time at which I try the
>> queries, one query will return results, and the other won't
>> (or the other way around).
>
> I am trying to find proof of that claim. The data isn't being
> uploaded frequently so I don't see how this kind of temporal
> flux is possible. As I said, stick to the predicate that
> provides the solution you seek. That should produce stable
> solutions.
>
> Kingsley
>>
>> -Rinke
>>
>> On Tue, Sep 8, 2015 at 4:58 PM Kingsley Idehen
>> > wrote:
>>
>> On 9/8/15 8:56 AM, Rinke Hoekstra wrote:
>>> Sure,
>>>
>>> Here's one for the area-codes-as-integers:
>>>
>>> 
>>> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbp%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fproperty%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbp%3AareaCode+020+.%0D%0A%7D+%0D%0A=text%2Fhtml_redir_for_
>>> subjs=121_redir_for_hrefs==3=on
>>
>> 

Re: [Dbpedia-discussion] [Spam] Re: Area code madness in DBPedia

[Paul Houle]

Note it is a general Liked Data problem that if you put together data from
the wild you will wind up with different ways of writing literals as well
as URIs that compete with literals.

SPARQL,  as it is today,  produces the same answers you would get from a
relational database if the Unique Name Assumption applies.  This is just as
true for literals as it is for URIs.  Some examples

* it is "reasonable" for people to write "8"^^xsd:byte,  and otherwise use
many different data types when they want to express an integer.
* say you are aggregating data into a vocabulary like foaf,  once again
there are multiple ways that people will encode email addresses no matter
what you tell them,  for instance as a literal string is reasonable,  but
also a mailto: URI is reasoanble.

One of the missing links in RDF tooling is something to normalize these
things.  In the wider world,  the U.N.A. definitely does not hold,  but if
you can enforce it in an area,  people know how to write SPARQL queries and
interpret the results -- otherwise it is a problem for a PhD thesis.

On Tue, Sep 8, 2015 at 2:03 PM, Rinke Hoekstra  wrote:

> Hi Kingsley and Dimitris,
>
> Thanks again for your replies.
>
> I suggest we leave it for now. I really wasn't asking you to solve my
> problem... it's trivial, I can come up with other equally relevant SPARQL
> examples if needed. I am well aware of the instability of the DBPedia
> property namespace, and only resorted to it because my normal route
> appeared to be blocked.
>
> I apologize if my initial email was overly polemic.
>
> I was just as surprised as you are that DBPedia behaved differently at
> different times: it shouldn't happen. As Kingsley says, the data is
> relatively stable. That's the reason I sent the email: just in case there
> was some weird bug on your end. I cannot provide proof other than what I
> told you.
>
> For now, a query on: ?city  dbpedia-owl:areaCode "020"^^xsd:string seems
> to work, so I'm good to go. I'll keep a backup of the DBPedia-property
> namespace-based solution just in case the temporal flux appears again. (and
> of course, I'll notify you immediately once that happens, with a full
> report)
>
> -Rinke
>
>
>
> On Tue, Sep 8, 2015 at 6:12 PM Kingsley Idehen 
> wrote:
>
>> On 9/8/15 11:13 AM, Rinke Hoekstra wrote:
>>
>> Hi Kingsley,
>>
>> Thanks for your help. I am aware that the two queries use a different
>> predicate; that's part of the problem.
>>
>>
>> You should stick with the predicate that provides the solution you seek.
>>
>
>
>>
>>
>> The issue is that depending on the time at which I try the queries, one
>> query will return results, and the other won't (or the other way around).
>>
>>
>> I am trying to find proof of that claim. The data isn't being uploaded
>> frequently so I don't see how this kind of temporal flux is possible. As I
>> said, stick to the predicate that provides the solution you seek. That
>> should produce stable solutions.
>>
>> Kingsley
>>
>>
>> -Rinke
>>
>> On Tue, Sep 8, 2015 at 4:58 PM Kingsley Idehen 
>> wrote:
>>
>>> On 9/8/15 8:56 AM, Rinke Hoekstra wrote:
>>>
>>> Sure,
>>>
>>> Here's one for the area-codes-as-integers:
>>>
>>>
>>> 
>>> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbp%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fproperty%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbp%3AareaCode+020+.%0D%0A%7D+%0D%0A=text%2Fhtml_redir_for_
>>> subjs=121_redir_for_hrefs==3=on
>>>
>>>
>>> That's a SPARQL query based on a query pattern that includes the
>>> predicate: 
>>> 
>>>  .
>>>
>>> Goto (note:  as opposed to  change in URL):
>>>
>>>
>>> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbp%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fproperty%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbp%3AareaCode+020+.%0D%0A%7D+%0D%0A=text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3=on
>>> 

Re: [Dbpedia-discussion] [Spam] Re: Area code madness in DBPedia

[Kingsley Idehen]

On 9/8/15 2:03 PM, Rinke Hoekstra wrote:
> Hi Kingsley and Dimitris,
>
> Thanks again for your replies.
>
> I suggest we leave it for now. I really wasn't asking you to solve my
> problem... it's trivial, I can come up with other equally relevant
> SPARQL examples if needed. I am well aware of the instability of the
> DBPedia property namespace, and only resorted to it because my normal
> route appeared to be blocked. 
>
> I apologize if my initial email was overly polemic.
>
> I was just as surprised as you are that DBPedia behaved differently at
> different times: it shouldn't happen. As Kingsley says, the data is
> relatively stable. That's the reason I sent the email: just in case
> there was some weird bug on your end. I cannot provide proof other
> than what I told you.
>
> For now, a query on: ?city  dbpedia-owl:areaCode "020"^^xsd:string
> seems to work, so I'm good to go. I'll keep a backup of the
> DBPedia-property namespace-based solution just in case the temporal
> flux appears again. (and of course, I'll notify you immediately once
> that happens, with a full report)
>
> -Rinke

Just share query URL if you have a situation where said URL provides
different solutions. If that occurs, we have a bug to investigate.

Kingsley
>
>
>
> On Tue, Sep 8, 2015 at 6:12 PM Kingsley Idehen  > wrote:
>
> On 9/8/15 11:13 AM, Rinke Hoekstra wrote:
>> Hi Kingsley,
>>
>> Thanks for your help. I am aware that the two queries use a
>> different predicate; that's part of the problem.
>
> You should stick with the predicate that provides the solution you
> seek.
>
>  
>
>
>>
>> The issue is that depending on the time at which I try the
>> queries, one query will return results, and the other won't (or
>> the other way around).
>
> I am trying to find proof of that claim. The data isn't being
> uploaded frequently so I don't see how this kind of temporal flux
> is possible. As I said, stick to the predicate that provides the
> solution you seek. That should produce stable solutions.
>
> Kingsley
>>
>> -Rinke
>>
>> On Tue, Sep 8, 2015 at 4:58 PM Kingsley Idehen
>> > wrote:
>>
>> On 9/8/15 8:56 AM, Rinke Hoekstra wrote:
>>> Sure,
>>>
>>> Here's one for the area-codes-as-integers:
>>>
>>> 
>>> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbp%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fproperty%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbp%3AareaCode+020+.%0D%0A%7D+%0D%0A=text%2Fhtml_redir_for_
>>> subjs=121_redir_for_hrefs==3=on
>>
>> That's a SPARQL query based on a query pattern that includes
>> the predicate: 
>>  .
>>
>> Goto (note:  as opposed to  change in URL):
>>
>> 
>> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbp%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fproperty%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbp%3AareaCode+020+.%0D%0A%7D+%0D%0A=text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3=on
>> 
>> 
>>
>>
>>>
>>> and here's the original query for area-codes-as-strings:
>>>
>>> 
>>> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbo%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fontology%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbo%3AareaCode+%22020%22%40en+.%0D%0A%7D+%0D%0A=text%2Fht
>>> 
>>> ml_redir_for_subjs=121_redir_for_hrefs==3=on
>>
>> That's based on a SPARQL query pattern that includes the
>> predicate 
>>  .
>>
>> Goto (note:  as opposed to  change in URL):
>>
>> 
>> 

Re: [Dbpedia-discussion] Area code madness in DBPedia

[Rinke Hoekstra]

Sure,

Here's one for the area-codes-as-integers:

http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbp%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fproperty%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbp%3AareaCode+020+.%0D%0A%7D+%0D%0A=text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3=on

and here's the original query for area-codes-as-strings:

http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbo%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fontology%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbo%3AareaCode+%22020%22%40en+.%0D%0A%7D+%0D%0A=text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3=on

Thanks,
Rinke


On Tue, Sep 8, 2015 at 2:43 PM Kingsley Idehen 
wrote:

> On 9/8/15 7:19 AM, Rinke Hoekstra wrote:
>
> Hi all,
>
> At the VU University Amsterdam, we're teaching various courses on the
> Semantic Web in which (understandably) DBPedia plays an important role.
>
> Over the past year's we have carefully groomed and curated a collection of
> example SPARQL queries against DBPedia. These queries revolve around cities
> with the "020" area code.
>
> To my surprise, these queries suddenly stopped working. Apparently because
> there has been a new release of DBPedia in which this was changed.
>
> ... however... it turns out that they work sometimes but do not work at
> other times... madness! ;-)
>
> A bit of background:
>
> The examples use the  property
> (i.e. a curated property), and assume the area codes are represented as
> string literals, e.g. "020", sometimes with an erroneous language tag.
>
> It now seems that in some versions of the DBPedia endpoint, the property <
> http://dbpedia.org/ontology/areaCode>
> has been demoted to  (i.e. a
> non-curated version) in *all* data: there is no place name with a
> dbpedia-owl:areaCode property. Even though the areaCode property is still
> defined in the ontology (at least, that's what I see when I point my
> browser at it).
>
> In addition to that (and much much worse), in some versions of the DBPedia
> endpoint, area codes are represented as *integers*, but are syntactically
> still presented as the value they had as strings. E.g. the area code for
> Amsterdam is represented as 020 rather than "020". Needless to say that 020
> as an integer is equal to 20 hm that's not what we want Area codes
> simply are not integers, they are strings, because the actual digits
> matter.
>
> (also, application developers should be able to rely on relative stability
> of statements that use the dbpedia ontology namespace, also, the ontology
> should only change monotonously: only add classes, properties etc., don't
> remove them!)
>
> In short:
> A couple of months ago, the area codes were represented as language tagged
> strings using the dbpedia-owl:areaCode property
>
> Yesterday morning at approx. 10 am, the area codes were represented as
> integers using the dbpedia-prop:areaCode property
>
> Yesterday evening, at approx. 10 pm, the area codes were represented as
> language tagged strings using the dbpedia-owl:areaCode property
>
> Today, at approx. 1 pm, the area codes were represented as integers using
> the dbpedia-prop:areaCode property
>
> ...
>
> It would be exceedingly nice if this could be fixed. Perhaps it has
> something to do with load balancing and different stores not being
> synchronized properly?
>
> -Rinke
>
> PS ... area codes may be strings... but they don't have to be
> language-tagged ;-)
>
>
>
> Rinke,
>
> Do you have a SPARQL query URL that demonstrates the kind of volatility
> that you are describing?
>
> --
> Regards,
>
> Kingsley Idehen   
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog 1: http://kidehen.blogspot.com
> Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
> Twitter Profile: https://twitter.com/kidehen
> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
>
>
--
___
Dbpedia-discussion mailing list
Dbpedia-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion

[Dbpedia-discussion] Fwd: Announcing the release of the Wikidata Query Service

[Markus Kroetzsch]

Hi all,

[Apologies if you have already seen this on other lists, but I figure 
this is quite useful to DBpedia developers as well.]


The Wikimedia Foundation has just announced its official live query 
service, based on SPARQL. You can do many things with this, since the 
data is quite rich. Best start with some example queries, found at:


https://www.mediawiki.org/wiki/Wikibase/Indexing/SPARQL_Query_Examples

The data is based on the current content of Wikidata, so if you find an 
error or omission, you can directly edit it (I think there might be an 
update lag of about 1 min, depending on traffic).


The data model is an evolution of our ISWC-14 paper "Introducing 
Wikidata to the Linked Data Web", but property IRIs have changed and 
some additional (meta) data and helper data was included. So best check 
out the up-to-date documentation for details:


https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format

The live RDF exported by Wikidata is still to be updated to yield all of 
the triples used in the SPARQL service. This is a matter of deploying 
some updates (the code is done), so it should happen soon.


Enjoy (but not too much; we are still gathering experiences with 
performance ;-),


Markus


 Forwarded Message 
Subject:[Wikidata] Announcing the release of the Wikidata Query Service
Date:   Mon, 7 Sep 2015 15:29:02 -0700
From:   Dan Garry 
Reply-To:   Discussion list for the Wikidata project.

To: wikidat...@lists.wikimedia.org



The Discovery Department at the Wikimedia Foundation is pleased to
announce the release of the Wikidata Query Service
! You can find
the interface for the service at https://query.wikidata.org.

The Wikidata Query Service is designed to let users run queries on the
data contained in Wikidata. The service uses SPARQL
 as the query language. You can
see some example queries in the user manual
.

Right now, the service is still in beta. This means that our goal
 
is

to monitor of the service usage and collect feedback about what people
think should be next. To do that, we've created the Wikidata Query
Service dashboard  to track usage
of the service, and we're in the process
 of setting up a feedback
mechanism for users of the service. Once we've got monitored the usage
of the service for a while and got user feedback, we'll decide on what's
next for development of the service.

If you have any feedback, suggestions, or comments, please do send an
email to the Discovery Department's public mailing list,
wikimedia-sea...@lists.wikimedia.org
.

Thanks,
Dan

--
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation


___
Wikidata mailing list
wikid...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
--
___
Dbpedia-discussion mailing list
Dbpedia-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion

Re: [Dbpedia-discussion] Area code madness in DBPedia

[Dimitris Kontokostas]

Hi Rinke & thanks for your report,

besides Kinglsey's comments, some notes from my side

On Tue, Sep 8, 2015 at 2:19 PM, Rinke Hoekstra  wrote:

> Hi all,
>
> At the VU University Amsterdam, we're teaching various courses on the
> Semantic Web in which (understandably) DBPedia plays an important role.
>
> Over the past year's we have carefully groomed and curated a collection of
> example SPARQL queries against DBPedia. These queries revolve around cities
> with the "020" area code.
>
> To my surprise, these queries suddenly stopped working. Apparently because
> there has been a new release of DBPedia in which this was changed.
>
> ... however... it turns out that they work sometimes but do not work at
> other times... madness! ;-)
>
> A bit of background:
>
> The examples use the  property
> (i.e. a curated property), and assume the area codes are represented as
> string literals, e.g. "020", sometimes with an erroneous language tag.
>

Since 2014 release (09/2014) we removed language tags from all xsd:strings
and introduced rdf:langString according to RDF 1.1
so dbpedia-owl:areaCode (not dbp:langCode) has no language tags in our
dumps for 1+ year.

dbp:areaCode comes from the infobox extractor that provides raw (and many
time inaccurate) data. The datatype of dbp:areaCode is decided on every
triple instance based on the data we get by a greedy algorithm



> It now seems that in some versions of the DBPedia endpoint, the property <
> http://dbpedia.org/ontology/areaCode> has been demoted to <
> http://dbpedia.org/property/areaCode> (i.e. a non-curated version) in
> *all* data: there is no place name with a dbpedia-owl:areaCode property.
> Even though the areaCode property is still defined in the ontology (at
> least, that's what I see when I point my browser at it).
>

Nothing is denoted, we use the mappings wiki to map infobox templates to
rdf, I can imagine that a template in Wikipedia possibly changed and the
mapping was not adjusted accordingly.
If you can provide example resources we can identify the source of the
error easier and fix it.


> In addition to that (and much much worse), in some versions of the DBPedia
> endpoint, area codes are represented as *integers*, but are syntactically
> still presented as the value they had as strings. E.g. the area code for
> Amsterdam is represented as 020 rather than "020". Needless to say that 020
> as an integer is equal to 20 hm that's not what we want Area codes
> simply are not integers, they are strings, because the actual digits
> matter.
>

as mentioned before, dbp:areaCode is not to be trusted, provided only for
completion. dbpedia-owl:areaCode should be consistent all times, if you
find a counter example please report it.


> (also, application developers should be able to rely on relative stability
> of statements that use the dbpedia ontology namespace, also, the ontology
> should only change monotonously: only add classes, properties etc., don't
> remove them!)
>

in general we agree but sometime you need to break some eggs to be able to
move forward and provide more consistent data.
However, I don't think we made any breaking changes to dbpedia-owl:areaCode
http://mappings.dbpedia.org/index.php?title=OntologyProperty:AreaCode=history


>
> In short:
> A couple of months ago, the area codes were represented as language tagged
> strings using the dbpedia-owl:areaCode property
>

this should be before August 2014. If you found it afterwards it is
probably a bug


> Yesterday morning at approx. 10 am, the area codes were represented as
> integers using the dbpedia-prop:areaCode property
>

see above comments regarding dbp


> Yesterday evening, at approx. 10 pm, the area codes were represented as
> language tagged strings using the dbpedia-owl:areaCode property
>

(Again) This should be a bug if true


>
> Today, at approx. 1 pm, the area codes were represented as integers using
> the dbpedia-prop:areaCode property
>

see above comments regarding dbp


>
>
> ...
>
> It would be exceedingly nice if this could be fixed. Perhaps it has
> something to do with load balancing and different stores not being
> synchronized properly?
>
> -Rinke
>
> PS ... area codes may be strings... but they don't have to be
> language-tagged ;-)
>
>
>
> --
>
> ___
> Dbpedia-discussion mailing list
> Dbpedia-discussion@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>
>


-- 
Kontokostas Dimitris
--
___
Dbpedia-discussion mailing list
Dbpedia-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion

Re: [Dbpedia-discussion] Fwd: Announcing the release of the Wikidata Query Service

[Markus Kroetzsch]

On 08.09.2015 16:48, Kingsley Idehen wrote:
> On 9/8/15 8:56 AM, Markus Kroetzsch wrote:
>> The Wikimedia Foundation has just announced its official live query
>> service, based on SPARQL. You can do many things with this, since the
>> data is quite rich. Best start with some example queries, found at:
>>
>> https://www.mediawiki.org/wiki/Wikibase/Indexing/SPARQL_Query_Examples
>>
>> The data is based on the current content of Wikidata, so if you find
>> an error or omission, you can directly edit it (I think there might be
>> an update lag of about 1 min, depending on traffic).
>
> Markus,
>
> Great news!
>
> A quick question, in regards to the excerpt above: can I use SPARQL
> query URLs against this service? In addition, can I use SPARQL FED along
> the following lines from other SPARQL Query service providers [1]:
>
> select * where {service  {select * where
> {?s a ?o} limit 10 } }

Yes, the UI we mostly advertise is not the plain SPARQL endpoint. What 
you want is https://query.wikidata.org/bigdata/namespace/wdq/sparql/

Your queries are [1] (text [2]) then.

Nonetheless, the recommended way to link to queries that users can then 
view and edit is to refer to https://query.wikidata.org like the 
examples do. Links to the plain endpoint query results (in various 
formats) should be included there. I think this is a known issue that 
will be fixed in due course.

Markus

[1] 
http://linkeddata.uriburner.com/sparql?default-graph-uri==select+*+where+{service+%3Chttps%3A%2F%2Fquery.wikidata.org%2Fbigdata%2Fnamespace%2Fwdq%2Fsparql%2F%3E+{select+*+where+{%3Fs+a+%3Fo}+limit+10+}+}==text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3000

[2] 
http://linkeddata.uriburner.com/sparql?default-graph-uri==select+*+where+{service+%3Chttps%3A%2F%2Fquery.wikidata.org%2Fbigdata%2Fnamespace%2Fwdq%2Fsparql%2F%3E+{select+*+where+{%3Fs+a+%3Fo}+limit+10+}+}==text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3000

>
> [1]
> http://linkeddata.uriburner.com/sparql?default-graph-uri==%0D%0Aselect+*+where+%7Bservice+%3Chttps%3A%2F%2Fquery.wikidata.org%2F%3E+%7Bselect+*+where+%7B%3Fs+a+%3Fo%7D+limit+10+%7D+%7D==text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3000
> - Query
>
> [2]
> http://linkeddata.uriburner.com/sparql?default-graph-uri==%0D%0Aselect+*+where+%7Bservice+%3Chttps%3A%2F%2Fquery.wikidata.org%2F%3E+%7Bselect+*+where+%7B%3Fs+a+%3Fo%7D+limit+10+%7D+%7D==text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3000
> -- Query Text in Editor
>
>
>
> --
>
>
>
> ___
> Dbpedia-discussion mailing list
> Dbpedia-discussion@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>

-- 
Markus Kroetzsch
Faculty of Computer Science
Technische Universität Dresden
+49 351 463 38486
http://korrekt.org/

--
___
Dbpedia-discussion mailing list
Dbpedia-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion

Re: [Dbpedia-discussion] [Spam] Re: Area code madness in DBPedia

[Rinke Hoekstra]

Hi Kingsley,

Thanks for your help. I am aware that the two queries use a different
predicate; that's part of the problem.

The issue is that depending on the time at which I try the queries, one
query will return results, and the other won't (or the other way around).

-Rinke

On Tue, Sep 8, 2015 at 4:58 PM Kingsley Idehen 
wrote:

> On 9/8/15 8:56 AM, Rinke Hoekstra wrote:
>
> Sure,
>
> Here's one for the area-codes-as-integers:
>
>
> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbp%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fproperty%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbp%3AareaCode+020+.%0D%0A%7D+%0D%0A=text%2Fhtml_redir_for_
> subjs=121_redir_for_hrefs==3=on
> 
>
>
> That's a SPARQL query based on a query pattern that includes the
> predicate: 
>  .
>
> Goto (note:  as opposed to  change in URL):
>
>
> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbp%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fproperty%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbp%3AareaCode+020+.%0D%0A%7D+%0D%0A=text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3=on
> 
>
>
>
> and here's the original query for area-codes-as-strings:
>
>
> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbo%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fontology%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbo%3AareaCode+%22020%22%40en+.%0D%0A%7D+%0D%0A=text%2Fht
> ml_redir_for_subjs=121_redir_for_hrefs==3=on
> 
>
>
> That's based on a SPARQL query pattern that includes the predicate
> 
>  .
>
> Goto (note:  as opposed to  change in URL):
>
>
> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbo%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fontology%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbo%3AareaCode+%22020%22%40en+.%0D%0A%7D+%0D%0A=text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3=on
> 

Re: [Dbpedia-discussion] [Spam] Re: Area code madness in DBPedia

[Kingsley Idehen]

On 9/8/15 11:13 AM, Rinke Hoekstra wrote:
> Hi Kingsley,
>
> Thanks for your help. I am aware that the two queries use a different
> predicate; that's part of the problem.

You should stick with the predicate that provides the solution you seek.

>
> The issue is that depending on the time at which I try the queries,
> one query will return results, and the other won't (or the other way
> around).

I am trying to find proof of that claim. The data isn't being uploaded
frequently so I don't see how this kind of temporal flux is possible. As
I said, stick to the predicate that provides the solution you seek. That
should produce stable solutions.

Kingsley
>
> -Rinke
>
> On Tue, Sep 8, 2015 at 4:58 PM Kingsley Idehen  > wrote:
>
> On 9/8/15 8:56 AM, Rinke Hoekstra wrote:
>> Sure,
>>
>> Here's one for the area-codes-as-integers:
>>
>> 
>> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbp%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fproperty%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbp%3AareaCode+020+.%0D%0A%7D+%0D%0A=text%2Fhtml_redir_for_
>> subjs=121_redir_for_hrefs==3=on
>> 
>> 
>
> That's a SPARQL query based on a query pattern that includes the
> predicate: 
>  .
>
> Goto (note:  as opposed to  change in URL):
>
> 
> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbp%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fproperty%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbp%3AareaCode+020+.%0D%0A%7D+%0D%0A=text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3=on
> 
> 
>
>
>>
>> and here's the original query for area-codes-as-strings:
>>
>> 
>> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbo%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fontology%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbo%3AareaCode+%22020%22%40en+.%0D%0A%7D+%0D%0A=text%2Fht
>> ml_redir_for_subjs=121_redir_for_hrefs==3=on
>> 
>> 
>
> That's based on a SPARQL query pattern that includes the predicate
> 
>  .
>
> Goto (note:  as opposed to  change in URL):
>
> 
> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbo%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fontology%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbo%3AareaCode+%22020%22%40en+.%0D%0A%7D+%0D%0A=text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3=on
> 
> 

Re: [Dbpedia-discussion] Fwd: Announcing the release of the Wikidata Query Service

[Kingsley Idehen]

On 9/8/15 11:26 AM, Markus Kroetzsch wrote:
>
>
> On 08.09.2015 16:48, Kingsley Idehen wrote:
>> On 9/8/15 8:56 AM, Markus Kroetzsch wrote:
>>> The Wikimedia Foundation has just announced its official live query
>>> service, based on SPARQL. You can do many things with this, since the
>>> data is quite rich. Best start with some example queries, found at:
>>>
>>> https://www.mediawiki.org/wiki/Wikibase/Indexing/SPARQL_Query_Examples
>>>
>>> The data is based on the current content of Wikidata, so if you find
>>> an error or omission, you can directly edit it (I think there might be
>>> an update lag of about 1 min, depending on traffic).
>>
>> Markus,
>>
>> Great news!
>>
>> A quick question, in regards to the excerpt above: can I use SPARQL
>> query URLs against this service? In addition, can I use SPARQL FED along
>> the following lines from other SPARQL Query service providers [1]:
>>
>> select * where {service  {select * where
>> {?s a ?o} limit 10 } }
>
> Yes, the UI we mostly advertise is not the plain SPARQL endpoint. What
> you want is https://query.wikidata.org/bigdata/namespace/wdq/sparql/
>
> Your queries are [1] (text [2]) then.
>
> Nonetheless, the recommended way to link to queries that users can
> then view and edit is to refer to https://query.wikidata.org like the
> examples do. Links to the plain endpoint query results (in various
> formats) should be included there. I think this is a known issue that
> will be fixed in due course.
>
> Markus
>
> [1]
> http://linkeddata.uriburner.com/sparql?default-graph-uri==select+*+where+{service+%3Chttps%3A%2F%2Fquery.wikidata.org%2Fbigdata%2Fnamespace%2Fwdq%2Fsparql%2F%3E+{select+*+where+{%3Fs+a+%3Fo}+limit+10+}+}==text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3000
>
> [2]
> http://linkeddata.uriburner.com/sparql?default-graph-uri==select+*+where+{service+%3Chttps%3A%2F%2Fquery.wikidata.org%2Fbigdata%2Fnamespace%2Fwdq%2Fsparql%2F%3E+{select+*+where+{%3Fs+a+%3Fo}+limit+10+}+}==text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3000
>

Great!

One more thing, if you click on [1] and then click on the HTTP URIs in
the solution, none of them resolve (bar schema.org). Is this an
oversight re., Linked Data deployment?

Ideally, you want to have your SPARQL endpoint enable data exploration
via HTTP URIs in the query solution, re., Linked Data.

Examples:

[1] http://id.nlm.nih.gov/mesh/query -- NIH Query Service
[2] http://rdf.disgenet.org/sparql/ -- Disgenet Query Service
[3] http://dbpedia.org/sparql -- DBpedia (which let's you explore via
Class instances in the query solution).

Kingsley
>>
>> [1]
>> http://linkeddata.uriburner.com/sparql?default-graph-uri==%0D%0Aselect+*+where+%7Bservice+%3Chttps%3A%2F%2Fquery.wikidata.org%2F%3E+%7Bselect+*+where+%7B%3Fs+a+%3Fo%7D+limit+10+%7D+%7D==text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3000
>>
>> - Query
>>
>> [2]
>> http://linkeddata.uriburner.com/sparql?default-graph-uri==%0D%0Aselect+*+where+%7Bservice+%3Chttps%3A%2F%2Fquery.wikidata.org%2F%3E+%7Bselect+*+where+%7B%3Fs+a+%3Fo%7D+limit+10+%7D+%7D==text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3000
>>
>> -- Query Text in Editor
>>
>>
>>
>> --
>>
>>
>>
>>
>> ___
>> Dbpedia-discussion mailing list
>> Dbpedia-discussion@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>>
>


-- 
Regards,

Kingsley Idehen   
Founder & CEO 
OpenLink Software 
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this




smime.p7s
Description: S/MIME Cryptographic Signature
--
___
Dbpedia-discussion mailing list
Dbpedia-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion

Re: [Dbpedia-discussion] [Wikidata] Fwd: Announcing the release of the Wikidata Query Service

[Markus Kroetzsch]

On 08.09.2015 18:22, Kingsley Idehen wrote:
...
> Great!
>
> One more thing, if you click on [1] and then click on the HTTP URIs in
> the solution, none of them resolve (bar schema.org). Is this an
> oversight re., Linked Data deployment?

Most of this should soon be fixed. The current ontology should 
definitely be available from http://wikiba.se/ontology soon, and it is 
also planned to publish archival versioned ontology files in addition.

Other URIs used in our results already do resolve, but the RDF is not 
up-to-date yet (see my recent question on the wikidata list). As I 
understand, most of this is a matter of deploying a variety of updates 
on a variety of server configurations on a variety of servers, so it may 
take a little until we have everything in place.

I don't know what the implementation status is for generated URIs like 
http://www.wikidata.org/value/8000228965cf554cf1baf641980f657d, since we 
cannot resolve them so easily. One way would be to redirect to a 
suitable DESCRIBE query result on the SPARQL endpoint. But this may 
require some more implementation work first. I think our main goal 
should be to have proper RDF replies for items and (all URI variants of) 
properties.

Markus

>
> Ideally, you want to have your SPARQL endpoint enable data exploration
> via HTTP URIs in the query solution, re., Linked Data.
>
> Examples:
>
> [1] http://id.nlm.nih.gov/mesh/query -- NIH Query Service
> [2] http://rdf.disgenet.org/sparql/ -- Disgenet Query Service
> [3] http://dbpedia.org/sparql -- DBpedia (which let's you explore via
> Class instances in the query solution).
>
> Kingsley
>>>
>>> [1]
>>> http://linkeddata.uriburner.com/sparql?default-graph-uri==%0D%0Aselect+*+where+%7Bservice+%3Chttps%3A%2F%2Fquery.wikidata.org%2F%3E+%7Bselect+*+where+%7B%3Fs+a+%3Fo%7D+limit+10+%7D+%7D==text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3000
>>>
>>> - Query
>>>
>>> [2]
>>> http://linkeddata.uriburner.com/sparql?default-graph-uri==%0D%0Aselect+*+where+%7Bservice+%3Chttps%3A%2F%2Fquery.wikidata.org%2F%3E+%7Bselect+*+where+%7B%3Fs+a+%3Fo%7D+limit+10+%7D+%7D==text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3000
>>>
>>> -- Query Text in Editor
>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>>
>>> ___
>>> Dbpedia-discussion mailing list
>>> Dbpedia-discussion@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>>>
>>
>
>
>
>
> ___
> Wikidata mailing list
> wikid...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>

-- 
Markus Kroetzsch
Faculty of Computer Science
Technische Universität Dresden
+49 351 463 38486
http://korrekt.org/

--
___
Dbpedia-discussion mailing list
Dbpedia-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion

Re: [Dbpedia-discussion] Area code madness in DBPedia

[Kingsley Idehen]

On 9/8/15 8:56 AM, Rinke Hoekstra wrote:
> Sure,
>
> Here's one for the area-codes-as-integers:
>
> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbp%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fproperty%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbp%3AareaCode+020+.%0D%0A%7D+%0D%0A=text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3=on

That's a SPARQL query based on a query pattern that includes the
predicate:  .

Goto (note:  as opposed to  change in URL):

http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbp%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fproperty%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbp%3AareaCode+020+.%0D%0A%7D+%0D%0A=text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3=on


>
> and here's the original query for area-codes-as-strings:
>
> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbo%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fontology%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbo%3AareaCode+%22020%22%40en+.%0D%0A%7D+%0D%0A=text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3=on

That's based on a SPARQL query pattern that includes the predicate
 .

Goto (note:  as opposed to  change in URL):

http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbo%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fontology%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbo%3AareaCode+%22020%22%40en+.%0D%0A%7D+%0D%0A=text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3=on


You have two different predicates in your query pattern. Naturally, they
would lead to two different solutions.

I still don't see the temporal issue in your post i.e., the claim that
somehow (within short timeframes) you have a solution that varies.

-- 
Regards,

Kingsley Idehen   
Founder & CEO 
OpenLink Software 
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this



smime.p7s
Description: S/MIME Cryptographic Signature
--
___
Dbpedia-discussion mailing list
Dbpedia-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion

Re: [Dbpedia-discussion] Fwd: Announcing the release of the Wikidata Query Service

[Kingsley Idehen]

On 9/8/15 8:56 AM, Markus Kroetzsch wrote:
> The Wikimedia Foundation has just announced its official live query
> service, based on SPARQL. You can do many things with this, since the
> data is quite rich. Best start with some example queries, found at:
>
> https://www.mediawiki.org/wiki/Wikibase/Indexing/SPARQL_Query_Examples
>
> The data is based on the current content of Wikidata, so if you find
> an error or omission, you can directly edit it (I think there might be
> an update lag of about 1 min, depending on traffic).

Markus,

Great news!

A quick question, in regards to the excerpt above: can I use SPARQL
query URLs against this service? In addition, can I use SPARQL FED along
the following lines from other SPARQL Query service providers [1]:

select * where {service  {select * where
{?s a ?o} limit 10 } }

[1]
http://linkeddata.uriburner.com/sparql?default-graph-uri==%0D%0Aselect+*+where+%7Bservice+%3Chttps%3A%2F%2Fquery.wikidata.org%2F%3E+%7Bselect+*+where+%7B%3Fs+a+%3Fo%7D+limit+10+%7D+%7D==text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3000
 
- Query

[2]
http://linkeddata.uriburner.com/sparql?default-graph-uri==%0D%0Aselect+*+where+%7Bservice+%3Chttps%3A%2F%2Fquery.wikidata.org%2F%3E+%7Bselect+*+where+%7B%3Fs+a+%3Fo%7D+limit+10+%7D+%7D==text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3000
-- Query Text in Editor

-- 
Regards,

Kingsley Idehen   
Founder & CEO 
OpenLink Software 
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this




smime.p7s
Description: S/MIME Cryptographic Signature
--
___
Dbpedia-discussion mailing list
Dbpedia-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion

Re: [Dbpedia-discussion] [Spam] Re: Area code madness in DBPedia

[Rinke Hoekstra]

Hi Kingsley and Dimitris,

Thanks again for your replies.

I suggest we leave it for now. I really wasn't asking you to solve my
problem... it's trivial, I can come up with other equally relevant SPARQL
examples if needed. I am well aware of the instability of the DBPedia
property namespace, and only resorted to it because my normal route
appeared to be blocked.

I apologize if my initial email was overly polemic.

I was just as surprised as you are that DBPedia behaved differently at
different times: it shouldn't happen. As Kingsley says, the data is
relatively stable. That's the reason I sent the email: just in case there
was some weird bug on your end. I cannot provide proof other than what I
told you.

For now, a query on: ?city  dbpedia-owl:areaCode "020"^^xsd:string seems to
work, so I'm good to go. I'll keep a backup of the DBPedia-property
namespace-based solution just in case the temporal flux appears again. (and
of course, I'll notify you immediately once that happens, with a full
report)

-Rinke



On Tue, Sep 8, 2015 at 6:12 PM Kingsley Idehen 
wrote:

> On 9/8/15 11:13 AM, Rinke Hoekstra wrote:
>
> Hi Kingsley,
>
> Thanks for your help. I am aware that the two queries use a different
> predicate; that's part of the problem.
>
>
> You should stick with the predicate that provides the solution you seek.
>


>
>
> The issue is that depending on the time at which I try the queries, one
> query will return results, and the other won't (or the other way around).
>
>
> I am trying to find proof of that claim. The data isn't being uploaded
> frequently so I don't see how this kind of temporal flux is possible. As I
> said, stick to the predicate that provides the solution you seek. That
> should produce stable solutions.
>
> Kingsley
>
>
> -Rinke
>
> On Tue, Sep 8, 2015 at 4:58 PM Kingsley Idehen 
> wrote:
>
>> On 9/8/15 8:56 AM, Rinke Hoekstra wrote:
>>
>> Sure,
>>
>> Here's one for the area-codes-as-integers:
>>
>>
>> 
>> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbp%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fproperty%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbp%3AareaCode+020+.%0D%0A%7D+%0D%0A=text%2Fhtml_redir_for_
>> subjs=121_redir_for_hrefs==3=on
>>
>>
>> That's a SPARQL query based on a query pattern that includes the
>> predicate: 
>> 
>>  .
>>
>> Goto (note:  as opposed to  change in URL):
>>
>>
>> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbp%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fproperty%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbp%3AareaCode+020+.%0D%0A%7D+%0D%0A=text%2Fhtml_redir_for_subjs=121_redir_for_hrefs==3=on
>> 
>>
>>
>>
>> and here's the original query for area-codes-as-strings:
>>
>>
>> 
>> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org=PREFIX+rdf%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%0D%0APREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+dbo%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fontology%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Fx+WHERE+%7B%0D%0A++%3Fx+dbo%3AareaCode+%22020%22%40en+.%0D%0A%7D+%0D%0A=text%2Fht
>>