Re: Fwd: Re: Added Requirement: Static Constraints

I preferred the term "static" over "global" because these constraints 
are not really about "all the nodes". In fact it is perfectly normal for 
static constraints to only be about certain triples (such as finding all 
triples that contain a property that was declared owl:deprecated).

In OO languages, the term static basically means "independent of 
specific instances". For example declaring a field static makes it 
globally accessible, without requiring an instance of the class.

But I agree that a foremost consideration should be intuitiveness, so if 
most people agree that "global" is a better term then I can happily live 
with it.

Holger


On 1/23/15, 3:23 AM, Jose Emilio Labra Gayo wrote:
> I have edited the requirements document with some comments and 
> objections. In the case of static constraints, I said that I didn't 
> like the name "static" and maybe, a more intuitive name, like "global" 
> constraints, could be more descriptive.
>
> But apart from that, I think a more technology neutral way to describe 
> what the requirement means is the selection of which nodes are 
> affected by a constraint description. Which in the case of "static 
> constraints" means all the nodes.
>
> One possibility is that the nodes affected are those nodes that are 
> instances of some specific class (which I think is the default 
> possibility in SPIN), another possibility is all the nodes ("static 
> constraints") and another one is to select one specific node (which 
> was also added as another requirement [1].
>
> I grouped those possibilities in a section titled "Selection of nodes" 
> [2] where I included the
> the three possibilities as three different requirements.
>
> I hope this clarifies the requirements in a more technology neutral way...
>
> [1] 
> https://www.w3.org/2014/data-shapes/wiki/Requirements#Evaluating_Constraints_for_a_Single_Node_Only
> [2] 
> https://www.w3.org/2014/data-shapes/wiki/Requirements#Selection_of_nodes
>
> Best regards, Jose Labra
>
>
> On Thu, Jan 22, 2015 at 3:50 PM, Karen Coyle <kcoyle@kcoyle.net 
> <mailto:kcoyle@kcoyle.net>> wrote:
>
>     Sorry, what I actually meant is: do we have a technology-neutral
>     statement of this that can be considered a requirement? We can't
>     word the requirements in terms of specific solutions.
>
>     However, at this point I've lost the original train of thought. it
>     seems that we started with: Wherever property X is used, it can be
>     used only once per graph.
>
>     That seems to me to be a convenient short-hand that can be defined
>     in other ways, as Peter and Holger have addressed. If so, then
>     this is a candidate for a macro in whatever interface is used.
>
>     kc
>
>
>     On 1/21/15 6:24 PM, Holger Knublauch wrote:
>
>         On 1/22/2015 11:16, Karen Coyle wrote:
>
>             The question, though, is how one
>             would express this without using SPIN
>
>
>         I assume you mean "without using SPARQL"?
>
>             - in other words, do we have a
>             generic way to express this requirement? I think it gets
>             back to how one
>             defines to target of the validation. Because these two
>             cases have two
>             different solutions, should they be different requirements?
>
>
>         Any complex constraint expressed using SPARQL can be turned into a
>         (SPIN/LDOM) template. This means that some experts can prepare
>         high-level lego bricks for people who don't know SPARQL. The items
>         mentioned under "Property declarations" are basically the most
>         common
>         patterns, and those should of course be built-in. We may
>         identify other
>         recurring patterns that should also be covered by built-ins
>         (such as
>         templates).
>
>         Holger
>
>
>
>
>     -- 
>     Karen Coyle
>     kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>     m: 1-510-435-8234 <tel:1-510-435-8234>
>     skype: kcoylenet/+1-510-984-3600 <tel:%2B1-510-984-3600>
>
>
>
>
> -- 
> Saludos, Labra

Received on Thursday, 22 January 2015 21:06:37 UTC