Re: [Wiki-research-l] [Wikitech-l] URL-addressable Predicate Calculus
Leila, I’m hoping to share some new knowledge representation techniques which could be of use to a number of projects for purposes of brainstorming. A number of new projects could be made possible with the new techniques; one could, for instance, envision a “wiki knowledgebase” project where predicate calculus expressions are hyperlinks to wiki experiences for users. As for what problem that I would like to see someday addressed, I hope to someday see advancements in the intersection of educational technology and crowdsourcing. We can envision crowdsourced: dialogue systems, intelligent tutoring systems, learning objects, textbooks, courses, and curricula [1][2]. Such projects could utilize a number of existing and new technologies, for instance Wikipedia, Wikibooks and Wikidata. Best regards, Adam [1] http://www.phoster.com/discussions/instructional-design-crowdsourcing-and-quality-control/ [2] http://www.phoster.com/discussions/crowdsourcing-dialogue-systems/ From: Wikitech-l on behalf of Leila Zia Sent: Wednesday, October 17, 2018 1:30:51 PM To: Research into Wikimedia content and communities Cc: wikitec...@lists.wikimedia.org Subject: Re: [Wikitech-l] [Wiki-research-l] URL-addressable Predicate Calculus Hi Adam, I'm missing the context here. Can you expand what problem you'd like to see addressed with the proposal you shared here? Best, Leila -- Leila Zia Senior Research Scientist, Lead Wikimedia Foundation On Wed, Oct 17, 2018 at 2:32 AM Adam Sobieski wrote: > > I would like to share, for discussion, some knowledge representation ideas > with respect to a URL-addressable predicate calculus. > > In the following examples, we can use the prefix “mw” for > “https://machine.wikipedia.org/” as per > xmlns:mw="https://machine.wikipedia.org/"; . > > mw:P1 > → https://machine.wikipedia.org/P1 > > mw:P1(arg0, arg1, arg2) > → https://machine.wikipedia.org/P1?A0=arg0&A1=arg1&A2=arg2 > > mw:P2 > → https://machine.wikipedia.org/P2 > > mw:P2 > → https://machine.wikipedia.org/P2?T0=t0&T1=t1&T2=t2 > > mw:P2(arg0, arg1, arg2) > → https://machine.wikipedia.org/P2?T0=t0&T1=t1&T2=t2&A0=arg0&A1=arg1&A2=arg2 > > Some points: > > 1. There is a mapping between each predicate calculus expression and a URL. > > 2. Navigating to mapped-to URLs results in processing on servers, e.g. PHP > scripts, which generates outputs. > > 3. The outputs vary per the content types requested via HTTP request headers. > > 4. The outputs may also vary per the languages requested via HTTP request > headers. > > 5. Navigating to https://machine.wikipedia.org/P1 generates a definition for > a predicate. > > 6. Navigating to https://machine.wikipedia.org/P2?T0=t0&T1=t1&T2=t2 generates > a definition for a predicate after assigning values to the parameters T0, T1, > T2. That is, a definition of a predicate is generated by a script, e.g. a PHP > script, which may vary its output based on the values for T0, T1, T2. > > 7. The possible values for T0, T1, T2, A0, A1, A2 may be drawn from the same > set. T0, T1, T2 need not be constrained to be types from a type system. > > 8. The values for T0, T1, T2, A0, A1, A2, that is t0, t1, t2, arg0, arg1, > arg2, could also each resolve to URLs. > > > Best regards, > Adam Sobieski > http://www.phoster.com/contents/ > > ___ > Wiki-research-l mailing list > Wiki-research-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wiki-research-l ___ Wikitech-l mailing list wikitec...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Re: [Wiki-research-l] URL-addressable Predicate Calculus
Finn Årup Nielsen,
Thank you. The techniques could be of use for a number of projects; I chose
http://machine.wikipedia.org for brainstorming purposes. I chose the example
prefix “mw” for “machine Wikipedia” but we could use another prefix. Similarly
with the placeholders for P1, P2.
My initial thoughts with respect to optional arguments and variadic predicates
are that URL-addressable syntaxes support variadic predicates if a system is
such that predicates can be defined with indefinite arity with respect to their
T0, T1, T2 and/or A0, A1, A2 parameters.
With respect to what is returned, my initial thinking is that the output varies
based on HTTP request headers, in particular Accept and Accept-Language . For
the Accept values of “text/html” or “application/xhtml+xml”, the content
returned could be human-readable wiki content. Other interesting formats to
consider include “application/rdf+xml”. For predicates without arguments, e.g.
for URLs resembling http://machine.wikipedia.org/P1 and
http://machine.wikipedia.org/P2?T0=t0&T1=t1&T2=t2 , the definitions of
predicates could be accessed or outputted.
With respect to error messages, in addition to the HTTP return codes of 4xx and
5xx, some requested formats may be able to encode error-related data.
Best regards,
Adam Sobieski
From: Wiki-research-l on behalf
of f...@imm.dtu.dk
Sent: Wednesday, October 17, 2018 7:40:52 AM
To: wiki-research-l@lists.wikimedia.org
Subject: Re: [Wiki-research-l] URL-addressable Predicate Calculus
Interesting.
Why would you have the prefix "https://machine.wikipedia.org/";. This
could be useful for many projects particular Wikidata, - not just
wikipedia. Would "https://wikimachine.org/"; or something be better?
"mw" is used as prefix for https://www.mediawiki.org and mw2sparql
https://www.mediawiki.org/wiki/MW2SPARQL
"mw:P2" does not seem to be supported by SPARQL and < and >
are not allowed in IRI_REF. Ordinary parentheses seems to be allowed.
The rule is '<' ([^<>"{}|^`\]-[#x00-#x20])* '>'
"mw:P1(arg0, arg1, arg2)" and "mw:P2" Why are there two
kinds of input? Wouldn't one suffice.
"mw:P1" Why are the identifiers prefixed with P? That collides with the
Wikidata properties.
"mw:P1(arg0, arg1, arg2)" This form does not allow for optional arguments.
There is also the question of what should be returned. There should be
room for error messaging.
One idea I have not followed through is to make an empty SPARQL endpoint
that would just provide SPARQL functions (extension functions). This way
the function could possibly be used in a federated query.
best regards
Finn Årup Nielsen
On 10/17/18 11:32 AM, Adam Sobieski wrote:
> I would like to share, for discussion, some knowledge representation ideas
> with respect to a URL-addressable predicate calculus.
>
> In the following examples, we can use the prefix “mw” for
> “https://machine.wikipedia.org/” as per
> xmlns:mw="https://machine.wikipedia.org/"; .
>
> mw:P1
> → https://machine.wikipedia.org/P1
>
> mw:P1(arg0, arg1, arg2)
> → https://machine.wikipedia.org/P1?A0=arg0&A1=arg1&A2=arg2
>
> mw:P2
> → https://machine.wikipedia.org/P2
>
> mw:P2
> → https://machine.wikipedia.org/P2?T0=t0&T1=t1&T2=t2
>
> mw:P2(arg0, arg1, arg2)
> → https://machine.wikipedia.org/P2?T0=t0&T1=t1&T2=t2&A0=arg0&A1=arg1&A2=arg2
>
> Some points:
>
> 1. There is a mapping between each predicate calculus expression and a URL.
>
> 2. Navigating to mapped-to URLs results in processing on servers, e.g. PHP
> scripts, which generates outputs.
>
> 3. The outputs vary per the content types requested via HTTP request headers.
>
> 4. The outputs may also vary per the languages requested via HTTP request
> headers.
>
> 5. Navigating to https://machine.wikipedia.org/P1 generates a definition for
> a predicate.
>
> 6. Navigating to https://machine.wikipedia.org/P2?T0=t0&T1=t1&T2=t2 generates
> a definition for a predicate after assigning values to the parameters T0, T1,
> T2. That is, a definition of a predicate is generated by a script, e.g. a PHP
> script, which may vary its output based on the values for T0, T1, T2.
>
> 7. The possible values for T0, T1, T2, A0, A1, A2 may be drawn from the same
> set. T0, T1, T2 need not be constrained to be types from a type system.
>
> 8. The values for T0, T1, T2, A0, A1, A2, that is t0, t1, t2, arg0, arg1,
> arg2, could also each resolve to URLs.
>
>
> Best regards,
> Adam Sobieski
> http://www.phoster.com/contents/
>
> ___
> Wiki-research-l mailing list
> Wiki-research-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
>
___
Wiki-research-l mailing list
Wiki-research-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
___
Wiki-research-l mailing list
Wiki-research-l@lists.wikimedia.org
https://li
Re: [Wiki-research-l] [Wikimedia Research Showcase] Wednesday October 17, 2018 at 11:30 AM (PST) 18:30 UTC
Just a reminder that this event starts in about 30 minutes. On Mon, Oct 15, 2018 at 11:34 AM, Janna Layton wrote: > Hello everyone, > > The next Research Showcase will be live-streamed this Wednesday, October > 17, 2018 at 11:30 AM (PST) 18:30 UTC. > > YouTube stream: https://www.youtube.com/watch?v=UJrJLWuNvXo > > As usual, you can join the conversation on IRC at #wikimedia-research. You > can also watch our past research showcases here: https://www.mediawiki.or > g/wiki/Wikimedia_Research/Showcase > > This month's presentation: > > *"Welcome" Changes? Descriptive and Injunctive Norms in a Wikipedia > Sub-Community* > > *By Jonathan T. Morgan, Wikimedia Foundation and Anna Filippova, GitHub* > > Open online communities rely on social norms for behavior regulation, > group cohesion, and sustainability. Research on the role of social norms > online has mainly focused on one source of influence at a time, making it > difficult to separate different normative influences and understand their > interactions. In this study, we use the Focus Theory to examine > interactions between several sources of normative influence in a Wikipedia > sub-community: local descriptive norms, local injunctive norms, and norms > imported from similar sub- communities. We find that exposure to injunctive > norms has a stronger effect than descriptive norms, that the likelihood of > performing a behavior is higher when both injunctive and descriptive norms > are congruent, and that conflicting social norms may negatively impact > pro-normative behavior. We contextualize these findings through member > interviews, and discuss their implications for both future research on > normative influence in online groups and the design of systems that support > open collaboration. > > > *The pipeline of online participation inequalities: The case of Wikipedia > Editing* > > *By Aaron Shaw, Northwestern University and Eszter Hargittai, University > of Zurich* > > Participatory platforms like the Wikimedia projects have unique potential > to facilitate more equitable knowledge production. However, digital > inequalities such as the Wikipedia gender gap undermine this democratizing > potential. In this talk, I present new research in which Eszter Hargittai > and I conceptualize a "pipeline" of online participation and model distinct > levels of awareness and behaviors necessary to become a contributor to the > participatory web. We test the theory in the case of Wikipedia editing, > using new survey data from a diverse, national sample of adult internet > users in the U.S. > > The results show that Wikipedia participation consistently reflects > inequalities of education and internet experiences and skills. We find that > the gender gap only emerges later in the pipeline whereas gaps along racial > and socioeconomic lines explain variations earlier in the pipeline. Our > findings underscore the multidimensionality of digital inequalities and > suggest new pathways toward closing knowledge gaps by highlighting the > importance of education and Internet skills. > > We conclude that future research and interventions to overcome digital > participation gaps should not focus exclusively on gender or class > differences in content creation, but expand to address multiple aspects of > digital inequality across pipelines of participation. In particular, when > it comes to overcoming gender gaps in the case of Wikipedia, our results > suggest that continued emphasis on recruiting female editors should include > efforts to disseminate the knowledge that Wikipedia can be edited. Our > findings support broader efforts to overcome knowledge- and skill-based > barriers to entry among potential contributors to the open web. > > > -- > Janna Layton > Administrative Assistant - Audiences & Technology > > Wikimedia Foundation > 1 Montgomery St. Suite 1600 > San Francisco, CA 94104 > -- Janna Layton Administrative Assistant - Audiences & Technology Wikimedia Foundation 1 Montgomery St. Suite 1600 San Francisco, CA 94104 ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Re: [Wiki-research-l] URL-addressable Predicate Calculus
Hi Adam, I'm missing the context here. Can you expand what problem you'd like to see addressed with the proposal you shared here? Best, Leila -- Leila Zia Senior Research Scientist, Lead Wikimedia Foundation On Wed, Oct 17, 2018 at 2:32 AM Adam Sobieski wrote: > > I would like to share, for discussion, some knowledge representation ideas > with respect to a URL-addressable predicate calculus. > > In the following examples, we can use the prefix “mw” for > “https://machine.wikipedia.org/” as per > xmlns:mw="https://machine.wikipedia.org/"; . > > mw:P1 > → https://machine.wikipedia.org/P1 > > mw:P1(arg0, arg1, arg2) > → https://machine.wikipedia.org/P1?A0=arg0&A1=arg1&A2=arg2 > > mw:P2 > → https://machine.wikipedia.org/P2 > > mw:P2 > → https://machine.wikipedia.org/P2?T0=t0&T1=t1&T2=t2 > > mw:P2(arg0, arg1, arg2) > → https://machine.wikipedia.org/P2?T0=t0&T1=t1&T2=t2&A0=arg0&A1=arg1&A2=arg2 > > Some points: > > 1. There is a mapping between each predicate calculus expression and a URL. > > 2. Navigating to mapped-to URLs results in processing on servers, e.g. PHP > scripts, which generates outputs. > > 3. The outputs vary per the content types requested via HTTP request headers. > > 4. The outputs may also vary per the languages requested via HTTP request > headers. > > 5. Navigating to https://machine.wikipedia.org/P1 generates a definition for > a predicate. > > 6. Navigating to https://machine.wikipedia.org/P2?T0=t0&T1=t1&T2=t2 generates > a definition for a predicate after assigning values to the parameters T0, T1, > T2. That is, a definition of a predicate is generated by a script, e.g. a PHP > script, which may vary its output based on the values for T0, T1, T2. > > 7. The possible values for T0, T1, T2, A0, A1, A2 may be drawn from the same > set. T0, T1, T2 need not be constrained to be types from a type system. > > 8. The values for T0, T1, T2, A0, A1, A2, that is t0, t1, t2, arg0, arg1, > arg2, could also each resolve to URLs. > > > Best regards, > Adam Sobieski > http://www.phoster.com/contents/ > > ___ > Wiki-research-l mailing list > Wiki-research-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wiki-research-l ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Re: [Wiki-research-l] URL-addressable Predicate Calculus
Interesting.
Why would you have the prefix "https://machine.wikipedia.org/";. This
could be useful for many projects particular Wikidata, - not just
wikipedia. Would "https://wikimachine.org/"; or something be better?
"mw" is used as prefix for https://www.mediawiki.org and mw2sparql
https://www.mediawiki.org/wiki/MW2SPARQL
"mw:P2" does not seem to be supported by SPARQL and < and >
are not allowed in IRI_REF. Ordinary parentheses seems to be allowed.
The rule is '<' ([^<>"{}|^`\]-[#x00-#x20])* '>'
"mw:P1(arg0, arg1, arg2)" and "mw:P2" Why are there two
kinds of input? Wouldn't one suffice.
"mw:P1" Why are the identifiers prefixed with P? That collides with the
Wikidata properties.
"mw:P1(arg0, arg1, arg2)" This form does not allow for optional arguments.
There is also the question of what should be returned. There should be
room for error messaging.
One idea I have not followed through is to make an empty SPARQL endpoint
that would just provide SPARQL functions (extension functions). This way
the function could possibly be used in a federated query.
best regards
Finn Årup Nielsen
On 10/17/18 11:32 AM, Adam Sobieski wrote:
I would like to share, for discussion, some knowledge representation ideas with
respect to a URL-addressable predicate calculus.
In the following examples, we can use the prefix “mw” for
“https://machine.wikipedia.org/” as per
xmlns:mw="https://machine.wikipedia.org/"; .
mw:P1
→ https://machine.wikipedia.org/P1
mw:P1(arg0, arg1, arg2)
→ https://machine.wikipedia.org/P1?A0=arg0&A1=arg1&A2=arg2
mw:P2
→ https://machine.wikipedia.org/P2
mw:P2
→ https://machine.wikipedia.org/P2?T0=t0&T1=t1&T2=t2
mw:P2(arg0, arg1, arg2)
→ https://machine.wikipedia.org/P2?T0=t0&T1=t1&T2=t2&A0=arg0&A1=arg1&A2=arg2
Some points:
1. There is a mapping between each predicate calculus expression and a URL.
2. Navigating to mapped-to URLs results in processing on servers, e.g. PHP
scripts, which generates outputs.
3. The outputs vary per the content types requested via HTTP request headers.
4. The outputs may also vary per the languages requested via HTTP request
headers.
5. Navigating to https://machine.wikipedia.org/P1 generates a definition for a
predicate.
6. Navigating to https://machine.wikipedia.org/P2?T0=t0&T1=t1&T2=t2 generates a
definition for a predicate after assigning values to the parameters T0, T1, T2. That
is, a definition of a predicate is generated by a script, e.g. a PHP script, which may
vary its output based on the values for T0, T1, T2.
7. The possible values for T0, T1, T2, A0, A1, A2 may be drawn from the same
set. T0, T1, T2 need not be constrained to be types from a type system.
8. The values for T0, T1, T2, A0, A1, A2, that is t0, t1, t2, arg0, arg1, arg2,
could also each resolve to URLs.
Best regards,
Adam Sobieski
http://www.phoster.com/contents/
___
Wiki-research-l mailing list
Wiki-research-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
___
Wiki-research-l mailing list
Wiki-research-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
[Wiki-research-l] URL-addressable Predicate Calculus
I would like to share, for discussion, some knowledge representation ideas with respect to a URL-addressable predicate calculus. In the following examples, we can use the prefix “mw” for “https://machine.wikipedia.org/” as per xmlns:mw="https://machine.wikipedia.org/"; . mw:P1 → https://machine.wikipedia.org/P1 mw:P1(arg0, arg1, arg2) → https://machine.wikipedia.org/P1?A0=arg0&A1=arg1&A2=arg2 mw:P2 → https://machine.wikipedia.org/P2 mw:P2 → https://machine.wikipedia.org/P2?T0=t0&T1=t1&T2=t2 mw:P2(arg0, arg1, arg2) → https://machine.wikipedia.org/P2?T0=t0&T1=t1&T2=t2&A0=arg0&A1=arg1&A2=arg2 Some points: 1. There is a mapping between each predicate calculus expression and a URL. 2. Navigating to mapped-to URLs results in processing on servers, e.g. PHP scripts, which generates outputs. 3. The outputs vary per the content types requested via HTTP request headers. 4. The outputs may also vary per the languages requested via HTTP request headers. 5. Navigating to https://machine.wikipedia.org/P1 generates a definition for a predicate. 6. Navigating to https://machine.wikipedia.org/P2?T0=t0&T1=t1&T2=t2 generates a definition for a predicate after assigning values to the parameters T0, T1, T2. That is, a definition of a predicate is generated by a script, e.g. a PHP script, which may vary its output based on the values for T0, T1, T2. 7. The possible values for T0, T1, T2, A0, A1, A2 may be drawn from the same set. T0, T1, T2 need not be constrained to be types from a type system. 8. The values for T0, T1, T2, A0, A1, A2, that is t0, t1, t2, arg0, arg1, arg2, could also each resolve to URLs. Best regards, Adam Sobieski http://www.phoster.com/contents/ ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
