I don't think anyone would want to use one ontology for all work, especially not a public ontology. I can imagine people using ontology extensions that are specific to the purpose of validation, and I've found them useful myself.
I'm not arguing against using SPARQL for validation. I do think that OWL offers a more natural-feeling language for discussing constraint for most folks, and I suppose that's why we've seen the introduction of extension languages like SPIN to intermediate a little between the user and plain SPARQL. --- A. Soroka The University of Virginia Library On Sep 16, 2013, at 11:00 PM, CODE4LIB automatic digest system wrote: > From: Karen Coyle <[email protected]> > Date: September 16, 2013 10:22:47 AM EDT > Subject: Re: CODE4LIB Digest - 12 Sep 2013 to 13 Sep 2013 (#2013-237) > > > On 9/16/13 6:29 AM, [email protected] wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I'd suggest that perhaps the confusion arises because "This instance is >> (not) 'valid' according to that ontology." might be inferred from an >> instance and an ontology (under certain conditions), and that's the soul of >> what we're asking when we define constraints on the data. Perhaps OWL can be >> used to express conditions of validity, as long as we represent the quality >> "valid" for use in inferences. > > Based on the results of the RDF Validation workshop [1], validation is being > expressed today as SPARQL rules. If you express the rules in OWL then > unfortunately you affect downstream re-use of your ontology, and that can > create a mess for inferencing and can add a burden onto any reasoners, which > are supposed to apply the OWL declarations. > > One participant at the workshop demonstrated a system that used the OWL > "constraints" as constraints, but only in a closed system. I think that the > use of SPARQL is superior because it does not affect the semantics of the > classes and properties, only the instance data, and that means that the same > properties can be validated differently for different applications or under > different contexts. As an example, one community may wish to say that their > metadata can have one and only one dc:title, while others may allow more than > one. You do not want to constrain dc:title throughout the Web, only your own > use of it. (Tom Baker and I presented a solution to this on the second day as > Application Profiles [2], as defined by the DC community). > > kc > [1] https://www.w3.org/2012/12/rdf-val/agenda > [2] > http://www.w3.org/2001/sw/wiki/images/e/ef/Baker-dc-abstract-model-revised.pdf
PGP.sig
Description: This is a digitally signed message part
