- From: Irene Polikoff <irene@topquadrant.com>
- Date: Sun, 13 Sep 2015 15:59:00 +0200
- To: <kcoyle@kcoyle.net>, "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
<Do they have to be different predicates? That wasn't clear to me. If so, then there is another use case for comparisons with the same predicate.> I donıt quite understand this. If the subject is the same and the predicate is the same, what is the constraint? Unless the language tags are involved, saying that the objects must be equal doesnıt make sense. If triples have the same subject, the same predicate and the same object (equal), they are the same triple. Saying that the objects must be different (not equal), doesnıt make sense either - they will always be different, otherwise it is the same triple. If the core of the issue is how to say something about literal objects in the triples that have the same subject, the same predicate and different language tags, then letıs have an example. I believe the example you had in the e-mail is S14 (see below) which is actually a cardinality constraint. Or am I mistaken? Coming back to SKOS, it has: S13: skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. This can be handled by three pairwise NotEqual constraints. But then, there is a language tag issue. There is no point comparing pref label in German to alt label in English. S14: A resource has no more than one value skos:prefLabel per language tag. I donıt believe this is about Equal or NotEqual constraint. This needs a cardinality constraint that takes into account language tag. S27 skos:related is disjoint with the property skos:broaderTransitive. This is handled by one NotEqual constraint S46 skos:exactMatch is disjoint with each of the properties skos:broadMatch and skos:relatedMatch. This is handled by two NotEqual constraints Which one of the SKOS requirements above did you have in mind? <And my question was: does this only operate on pairs? As I recall from the meeting last week, these constraints were described as operating on pairs only. That's what I'm responding to. I may have remembered wrong.> I see a difference between equal/notEqual and >/< comparison in that for equal/notEqual one could possibly allow more than two variables (properties), but it doesnıt make sense to do so for >/< (unless the idea is to say something like property1>property2>property3>Š>propertyN - which may be a useful short cut in some cases, but certainly doesnıt strike me as a ³basic² use case). So, the question may be should multiple variables be allowed for equal/notEqual or should there be another two ³core² constraints AllSame and AllDifferent that would take more than two input properties. <There is still the question of order for > and <.> Yes, but I assume this would be explained in the spec - one way or another. It would make sense to say that property1 goes before the operator and property2 after such as property1>property2 and property1<property2. <These ARE basics. It sounds like you are saying "Don't bring up any more use cases" but I don't accept this. If the standard doesn't respond to very common use cases, it cannot succeed.> As proposed, the standard is responding to ALL use cases by way of its extensibility. I didnıt realize that all the use cases had to be covered in ³core². If all or most of use cases have to be covered in ³core², then I believe the question on how to practically accomplish this canıt be ignored. As the number of different use case/ language constructs grows, the options I see are to either significantly increase: -The number of people who do the work. They will, of course, have to be following the pre-agreed approach and direction. Otherwise, a bigger group will actually impact the productivity in a negative way. or -The duration of the working group. As with software development, I suspect this would only work the if the group delivers the underlying approach and architecture first with some limited numbers of definitions, then deliver additional definitions in increments. Irene On 9/13/15, 2:45 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote: > > >On 9/13/15 11:50 AM, Irene Polikoff wrote: >> Karen, >> >> I believe the constraints in Holger's email are for comparing object >> values of triples with the same subject and two different >> predicates. >> > >Do they have to be different predicates? That wasn't clear to me. If so, >then there is another use case for comparisons with the same predicate. > >> What constraints are you taking about? >> >> Those for the same subjects or for different subjects (such as two >> resources can't have the same pref label)? > >My use case was the one I gave in my example - same predicate but >different values. > >> >> If it is for the same subject and the idea is to say that the values >> for prop1, prop2, prop3, ..., propN must be all the same or all >> different, then may be it could accomplished with Equal and NotEqual >> constraints by allowing an arbitrary number of arguments. > >And my question was: does this only operate on pairs? As I recall from >the meeting last week, these constraints were described as operating on >pairs only. That's what I'm responding to. I may have remembered wrong. > >There is still the question of order for > and <. > >> >> Then, bringing in the language tag consideration is another story - I >> would think this requires another, somewhat different set of >> constraints. >> >> If it is about different subjects, then I think this is yet another >> set of constraints. >> >> The more situations we will try to cover, the larger the language >> grows. In theory not an issue, perhaps, but in practice it is - as >> this becomes too big of a task for a small number of active working >> group participants to identify, name, design, discuss, implement, >> etc. Thus, a suggestion to put some basics in place and to enable the >> extended community to build and socialize additional constraints. > >These ARE basics. It sounds like you are saying "Don't bring up any more >use cases" but I don't accept this. If the standard doesn't respond to >very common use cases, it cannot succeed. > >kc > >> >> Irene >> >> Sent from my iPhone >> >>> On Sep 13, 2015, at 11:25 AM, Karen Coyle <kcoyle@kcoyle.net> >>> wrote: >>> >>> I agree that the SKOS rules go beyond my previous example, and we >>> do have a use case that requires the ability to follow the rules >>> inherent in SKOS. Since this is a common case, we should probably >>> detail it and make sure that it is covered. However, the point was >>> to ask what happens to comparisons that are >2, and to point out >>> that sometimes that number can be large, such as where different >>> language versions are used, since the actual number of potential >>> languages (cf. Wikipedia) is in the hundreds, at least. >>> >>> kc >>> >>>> On 9/13/15 10:52 AM, Irene Polikoff wrote: Thus, the appropriate >>>> constraint is the one on cardinality (max 1), but it needs to >>>> take into account language tag. >>>> >>>> If one was to follow this line of thinking, in addition to >>>> regular cardinality constraints, there would need to be >>>> cardinality constraints within a language. >>> >>> -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: >>> 1-510-435-8234 skype: kcoylenet/+1-510-984-3600 >> > >-- >Karen Coyle >kcoyle@kcoyle.net http://kcoyle.net >m: 1-510-435-8234 >skype: kcoylenet/+1-510-984-3600
Received on Sunday, 13 September 2015 13:59:33 UTC