Hi Holger,
On 2/16/15 12:31 AM, Holger Knublauch wrote:
> On 2/16/2015 8:31, Antoine Isaac wrote:
>> 2. In data you curate, would classes accurately pinpoint validation targets?
>>
>> Very often yes, but there will be exceptions, like SKOS' S14: "A resource has no more than one value of skos:prefLabel per language tag."
>> http://www.w3.org/TR/skos-reference/#L1567
>
> Just to make sure we are talking about the same things here: the current discussion in the WG distinguishes between constraints and shapes.
>
> Constraints are individual conditions that can be verified. Constraints may either apply to a given start node (often the subject, ?this in SPIN) or they may be global. Global constraints can be used to represent, for example, that "a graph must contain exactly one instance of foaf:Person", or "for any subject, skos:prefLabel should only have one value per language tag". (The latter is "global" because the domain of skos:prefLabel is rdfs:Resource, i.e. there is no natural class to attach it to - it could also be attached to the class rdfs:Resource in case these are interpreted globally).
>
> A "shape" is a group of non-global constraints that talk about the same starting node. This concept is very similar to how most mainstream technologies and OWL use classes, i.e. as a container of property characteristics that represent similar instances. Compare it to a class containing owl:Restrictions.
Thanks for the clarification!
I had understood the idea behind the 'shapes' but quite failed to get that they were not the only constructs the group is preparing.
If there are other 'constraints' that would tackle the need for property-centered validation, then it looks better (well, even though I've not seen them yet)
>>
>>>
>>> 3. Anything you want to say about treating shapes themselves as classes to be used in instance data?
>>
>>
>> Using classes to represent shapes would at least require a new mechanism to relate these classes to the graphs where they 'apply' (i.e. the graphs where the specified constraint should hold). I'm not sure it's really great from the general perspective of RDFS/OWL as knowledge representation languages. I.e. we would restrict the scope of some classes to certain graphs, while RDFS/OWL classes have been defined with an open world assumption since the beginning.
>
> The same seems to apply to "shapes" being not classes. Note that the WG is aiming at producing a new language, i.e. none of the existing RDFS/OWL classes would contain (LDOM) definitions yet. From the day that the new standard would be introduced, the owners of the RDFS/OWL ontologies can decide whether they want to define stricter constraints on their instances or not. (Unless the WG decides to repurpose OWL for closed-world checking, but this seems unlikely at this stage for these very reasons). But the existing class definitions may serve as a natural structure to attach constraints to.
I'm still a bit hesitant about the idea of having 'new-style classes' co-exist with 'old-style classes' in modeling world. The first option with explicit shapes seems a bit less dangerous way to go for data modelers.
I agree it should be doable to do it with 'new-style classes', in theory; but the other pattern looks more appealing to me.
Antoine
|