- From: Martynas Jusevičius <martynas@graphity.org>
- Date: Fri, 27 Nov 2015 17:05:53 +0100
- To: "henry.story@bblfish.net" <henry.story@bblfish.net>
- Cc: Semantic Web <semantic-web@w3.org>
Well if you decide to actually use RDF data from HTML forms instead of developing new language for it, give us a shout: http://graphityhq.com/technology/graphity-client#features Martynas graphityhq.com On Fri, Nov 27, 2015 at 4:51 PM, henry.story@bblfish.net <henry.story@bblfish.net> wrote: > >> On 27 Nov 2015, at 15:44, Martynas Jusevičius <martynas@graphity.org> wrote: >> >> A new language? Really? Like 95% SPARQL, but incompatible? > > yes. It's not the same thing. It can re-use a lot of what is there, but > clearly we are not querying a graph. It may just require to be a subset of > SPARQL. SPARQL itself is a variation of N3. And SPARQL PATCH is itself > an extension of SPARQL. This is not the first time this happens. > >> >> This way you are aiming for the anecdotal xkcd 15 incompatible >> standards situation. That is exactly what is wrong with the >> semantic/LD ecosystem. >> There is a specification that does exactly what you want: encode HTML >> form data as RDF. It is called RDF/POST and is well specified. >> Essentially it's just another RDF syntax, we even have written a >> streaming parser for it. >> >> So the technology is not the issue. The issue is the "IndieWeb folks" >> (whatever IndieWeb is?) that are unwilling to, or unable to, learn new >> technologies that are best suited for the problem at hand. We need to >> educate developers to reuse existing specifications, not create new >> ones at every turn. >> > > Don't really want to get in a discussion about all of that. I have other > things to do. This was just a thought. It may interest people, other not. > >> >> Martynas >> >> On Fri, Nov 27, 2015 at 3:26 PM, henry.story@bblfish.net >> <henry.story@bblfish.net> wrote: >>> >>>> On 27 Nov 2015, at 14:21, Martynas Jusevičius <martynas@graphity.org> wrote: >>>> >>>> How would determine the datatypes of the values, or which values >>>> should be literals and which URIs? You can only do that in the WHERE >>>> clause (using BIND() for example), and it has to operate over an RDF >>>> graph. Or WHERE has to be empty as I suggested before. >>> >>> IN SPARQL the query has to operate over a GRAPH, but this is meant to >>> be a new language insipired and re-using as much of the work from SPARQL >>> as possible. Ideally one could take a few subsections of sparql and >>> produce it. >>> >>> You are right that one needs to find a way to deal with datatypes. >>> I point out in a number of places in >>> https://github.com/w3c-social/webmention/issues/11 >>> >>> It would have been easy if one had been able to just specify the >>> datatype in the CONSTRUCT. >>> >>> >>> @prefix foaf: <http://xmlns.com/foaf/0.1/>. >>> @prefix contact: <http://www.w3.org/2000/10/swap/pim/contact#> . >>> >>> CONSTRUCT { >>> [] foaf:name ?name; >>> foaf:age ?age^^xsd:integer; >>> contact:home >>> [ a contact:ContactLocation; >>> contact:address [ contact:city ?city; >>> contact:country ?country; >>> contact:postalCode ?zip; >>> contact:street ?street >>> ] . >>> } WITH ?name ?age ?city ?country ?zip ?street >>> >>> >>> So yes, this is just an initial proposal, it is not fully fleshed out, >>> and one needs to see if the IndieWeb Camp folks actually would even want >>> to play along. But as I spent a few hours on this, perhaps others may >>> have other use cases for which they would find such a tool useful. >>> >>> >>> >>>> >>>> On Fri, Nov 27, 2015 at 3:17 PM, henry.story@bblfish.net >>>> <henry.story@bblfish.net> wrote: >>>>> >>>>> On 27 Nov 2015, at 14:13, Martynas Jusevičius <martynas@graphity.org> wrote: >>>>> >>>>> Well then you need a canonical mapping from www-encoded data to RDF before >>>>> you query. CONSTRUCT could work on that, but it will not help you define it. >>>>> >>>>> The only existing one I know is RDF/POST. >>>>> >>>>> >>>>> I don't agree that you need a canonical mapping from www-encoded data to >>>>> rdf. >>>>> >>>>> You can think of the attribute values as the response-set of a missing >>>>> WHERE. >>>>> So you only actually need the CONSTRUCT part. >>>>> >>>>> You do of course need the resource you are POSTing to, to return something >>>>> that >>>>> points to the transormation. This could be done with a Link header such as >>>>> >>>>> 200 Ok >>>>> Link: <http://w3c.org/social/WebMention>; rel="urlencoded" >>>>> >>>>> >>>>> as explained in https://github.com/w3c-social/webmention/issues/11 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, 27 Nov 2015 at 14:53, henry.story@bblfish.net >>>>> <henry.story@bblfish.net> wrote: >>>>>> >>>>>> >>>>>>> On 27 Nov 2015, at 11:17, Martynas Jusevičius <martynas@graphity.org> >>>>>>> wrote: >>>>>>> >>>>>>> Where did you find the CONSTRUCT ... WITH query form though? >>>>>> >>>>>> I just invented it, a quick first idea for people to get the gist. >>>>>> Clearly what would be needed would be also some way of having optional >>>>>> form attributes. >>>>>> >>>>>>> >>>>>>> It could probably be just CONSTRUCT template with an empty WHERE {} on >>>>>>> which you apply the variable bindings. >>>>>> >>>>>> I don't think that would work. We are actually just doing a construct on >>>>>> an result set. The parameter values in the www-encoded POSTed content >>>>>> can be thought of as a result set. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> On Thu, Nov 26, 2015 at 7:53 PM, henry.story@bblfish.net >>>>>>> <henry.story@bblfish.net> wrote: >>>>>>>> That requires people getting people making such forms to learn RDF, >>>>>>>> which if >>>>>>>> you >>>>>>>> read the types of answers to issue 11 linked below, or if you interact >>>>>>>> with >>>>>>>> IndieWeb folks, >>>>>>>> you'll understand is unlikely. What is less unlikely is that the >>>>>>>> server >>>>>>>> provide a link >>>>>>>> to an interpretation. The interpretation can then be made machine >>>>>>>> readable >>>>>>>> in the way >>>>>>>> proposed. >>>>>>>> >>>>>>>> >>>>>>>> On 26 Nov 2015, at 18:47, Martynas Jusevičius <martynas@graphity.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Can't you reuse RDF/POST for that? >>>>>>>> http://www.lsrn.org/semweb/rdfpost.html >>>>>>>> >>>>>>>> On Thu, 26 Nov 2015 at 19:38, henry.story@bblfish.net >>>>>>>> <henry.story@bblfish.net> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> following a discussion with the IndieWeb folks on a pingback >>>>>>>>> protocol, >>>>>>>>> where we are trying to satisfy the constraints that the IndieWeb folks >>>>>>>>> live >>>>>>>>> by - which is very close to the first generation of the Web - and yet >>>>>>>>> who >>>>>>>>> want to work in a global web of data - the following requirement came >>>>>>>>> up: how can a resource make explicit its interpretation of web forms. >>>>>>>>> >>>>>>>>> I write this up here: >>>>>>>>> https://github.com/w3c-social/webmention/issues/11 >>>>>>>>> >>>>>>>>> Essentially this would not entail very much other than creating a Link >>>>>>>>> realation >>>>>>>>> that could point to something like a document that would contain a >>>>>>>>> mapping >>>>>>>>> that could look like this >>>>>>>>> >>>>>>>>> [[ >>>>>>>>> @prefix foaf: <http://xmlns.com/foaf/0.1/>. >>>>>>>>> @prefix contact: <http://www.w3.org/2000/10/swap/pim/contact#> . >>>>>>>>> >>>>>>>>> CONSTRUCT { >>>>>>>>> [] foaf:name ?name; >>>>>>>>> foaf:age ?age; >>>>>>>>> contact:home >>>>>>>>> [ a contact:ContactLocation; >>>>>>>>> contact:address [ contact:city ?city; >>>>>>>>> contact:country ?country; >>>>>>>>> contact:postalCode ?zip; >>>>>>>>> contact:street ?street >>>>>>>>> ] . >>>>>>>>> } WITH ?name ?age ?city ?country ?zip ?street >>>>>>>>> ]] >>>>>>>>> >>>>>>>>> where ?name ?age ?city etc would be the values of the properties taken >>>>>>>>> from the >>>>>>>>> application/x-www-form-urlencoded content sent in a POST. >>>>>>>>> >>>>>>>>> This should not be that much work to specify I suppose, especially for >>>>>>>>> the >>>>>>>>> SPARQL knowledgeable folks. >>>>>>>>> >>>>>>>>> Any feedback? >>>>>>>>> >>>>>>>>> Henry >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >
Received on Friday, 27 November 2015 16:06:29 UTC