Re: Functions in N3 (was: Re: What Happened to the Semantic Web?)

On Dec 2, 2017, at 10:02 PM, Eric Prud'hommeaux <eric@w3.org> wrote:
> 
> * Simon.Cox@csiro.au <Simon.Cox@csiro.au> [2017-12-03 05:00+0000]
>> Have a talk to your w3c staff contact. It is usually possible to fix obvious things like this. Particularly if the namespace was already allocated, so the URI set is already implied.
> 
> It's easy to fix obvious things. The question we have to ask is if this is indeed obvious and non-contentious.
> 
> When W3C convenes a Working Group, the process involves knocking on a lot of doors to get all the relevant parties into the room. The WG tools on some stuff and asks widely and loudly for implementations and review. The product is that the resulting documents have been the subject of a lot of experimentation by the time they're published. Namespace documents don't require as much ceremony, but namespace documents attached to a Rec are making a best-faith effort to codify the terms defined in the Rec.
> 
> Typically, ns docs have many terms and include a namespace policy which claims stability after the accompanying specs make it through LC. <http://www.w3.org/ns/sparql> has one exciting term in it and probably even if we totally screw up and change it a hundred times, nothing out there will break. That said, it would be I believe it would be appropriate to contact at least the members of the SPARQL 1.1 WG to settle questions like:
> 
>  Do we duplicate names that are already defined in XPath/XML Schema?
> 
>  Are SPARQL implementations expected to recognize the newly-minted names? If not, how do we distinguish the ones which do?
> 
>  What are our unknown unknowns?
> 
> The last one is the hardest and is why we reach out to as many folks as possible.

Hi Eric,

Others may remember differently, but my recollection was that we set up /ns/sparql with the explicit intention of assigning IRIs to all the functions and aggregates from 1.1 Query. I believe I was the one who requested it as part of the 1.1 Service Description work. I have put the RDF I had intended to be put under /ns/sparql at [1]. You’ll see that it was only ever a set of rdf:type statements—we never got as far as defining/modeling anything more complex. My goal was simply to get IRIs assigned so that we could think about next steps later.

My opinions on the other question is: implementations needn’t recognize these IRIs as functions as there is nothing about that in the Rec or the test suite (though I think it would be a good idea for implementations to do it). I don’t have an explicit way to identify implementations that *do* recognize them, but this is exactly the use case for the Service Description sd:feature term and sd:Feature class. Perhaps we can talk about minting a feature IRI to indicate such support.

Thanks,
Greg

[1] https://gist.github.com/kasei/c057dde3555559d90e7579f641efbf27

Received on Sunday, 3 December 2017 06:21:54 UTC