Hi,

Some quick reaction


>>
>> The requirement of not hijacking existing formal specification languages
>> for expressing constraints that rely on different semantics has not been
>> raised yet.
>
> No, actually, as Tom says below, I raised that point yesterday in the meeting. Rather clearly, I believe.


I meant that it's not yet been recorded in our database.
I understood the original question as an attempt to capture the call's discussion formally...


  
>>
>> In fact the discussions in the RDF-Shapes group showed that for a
>> significant part of the RDF community, it doesn't matter. They just
>> re-use the OWL syntax with closed world semantics.
>
> I would not characterize it that way. There is *a* group that favors re-using OWL syntax, led by Kendall Clarke. There is another group that favors using SPARQL


I'm using the word 'community' in a lose way, which includes user base. People who use Kendall's tools count: they vote with their feet, so to say. More formally, their requirements are met by Kendall's solution, so it partly validates it in spite of all other potential shortcomings of the approach.
(the same would apply for users of tools that follow other approaches, of course; I'm not taking sides)

>(primarily in the form of SPIN). Each of these, unfortunately, has a "dog in the fight" -- that is, each has a product they are selling that uses that technique. And because these are the validators that are currently available, people use them. Yet I can point to examples where this causes significant problems (Tom and I will present some in Austin).
>
> In an attempt at neutrality, EricP (sorry, can't spell his last name :( ) has proposed a third way, shape expressions, ShEx. Shape expressions *could be* similar to the DSP, in that it could be a way to define constraints locally that are parallel to, but do not interfere with, the RDF or OWL semantics of the vocabulary.
>
> Another important point: that group is focused solely on data validation. Data validation by itself is not an application profile.


Yes, AP imply documentation etc.
(though in fact it would be even better an argument in favor of tweaking OWL semantics! people get the syntax, they just don't get the open world assumption ;-) )
  
>
>>
>> I am not comfortable with it either, but ultimately we can't really
>> overrun whatver the RDF Shape group decides to be acceptable.
>> I'd be in favour of raising it, but rather as an issue, or a desirable
>> design principle, rather than a formal requirement.
>
> Like Tom, I think it is THE formal requirement. And since the ShEx group has not yet met, we do not know what they will decide. Also, they are contending with commercial interests inside the group, and we do not have that constraint. I think we can lead by example here, since we already have the DSP. If we can develop a test suite for the DSP, modify any areas that need modification, AND provide an easy way for people to create simple APs, then I think we will have created the "Dublin Core" for people entering into the linked data world, in the way that Dublin Core elements were an entry into machine-readable metadata.
>


That's right, but I'd seriously consider dropping the formal requirement and DSP, if the RDF group makes something that matches our requirements (expect the one design principle we're discussing now) in whatever semantic trick is validated by that group.
This is my point: it's good to make design principles explicit and encourage them; but it's less important than meeting the 'business' requirements, which are in our case the (formal and informal) expressiveness of the AP solution.

Best,

Antoine