Ethan, if you are interested in "dialoguing" about this topic, I suspect
this isn't the forum for it. I don't think that W3C has yet set up a
public list on rdf validation (the meeting participants need to form an
actual W3C group for that to happen, and I hope that won't take too
long), but there should be one soon. It's really rather useless to keep
telling *me* this, since I'm not arguing for any particular technology,
just reporting what I've learned in the last few weeks about what others
are doing.
That is, if you are interested in having an exchange of ideas about this
topic rather than repeatedly trying to convince me that what I'm saying
is wrong. It's like you're trying to convince me that I really did not
hear what I did. But I did hear it. Maybe all of those people are wrong;
maybe you could explain to them that they are wrong. But if you care
about this, then you need to be talking to them.
kc
On 9/16/13 7:40 AM, Ethan Gruber wrote:
Using SPARQL to validate seems like tremendous overhead. From the Gerber
abstract: "A total of 55 rules have been defined representing the
constraints and requirements of the OA Specification and Ontology. For each
rule we have defined a SPARQL query to check compliance." I hope this isn't
55 SPARQL queries per RDF resource.
Europeana's review of schematron indicated what I pointed out earlier, that
it confines one to using RDF/XML, which is "sub-optimal" in their own
words. One could accept RDF in any serialization and then run it through
an RDF processor, like rapper (http://librdf.org/raptor/rapper.html), into
XML and then validate. Eventually, when XPath/XSLT 3 supports JSON and
other non-XML data models, theoretically, schematron might then be able to
validate other serializations of RDF. Ditto for XForms, which we are using
to validate RDF/XML. Obviously, this is sub-optimal because our workflow
doesn't yet account for non-XML data. We will probably go with the rapper
intermediary process until XForms 2 is released.
Ethan
On Mon, Sep 16, 2013 at 10:22 AM, Karen Coyle <li...@kcoyle.net> wrote:
On 9/16/13 6:29 AM, aj...@virginia.edu 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<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<http://www.w3.org/2001/sw/wiki/images/e/ef/Baker-dc-abstract-model-revised.pdf>
- ---
A. Soroka
The University of Virginia Library
On Sep 13, 2013, at 11:00 PM, CODE4LIB automatic digest system wrote:
Also, remember that OWL does NOT constrain your data, it constrains only
the inferences that you can make about your data. OWL operates at the
ontology level, not the data level. (The OWL 2 documentation makes this
more clear, in my reading of it. I agree that the example you cite sure
looks like a constraint on the data... it's very confusing.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJSNwe2AAoJEATpPY**SyaoIkwLcIAK+**sMzy1XkqLStg94F2I40pe
0DepjqVhdPnaDS1Msg7pd7c7iC0L5N**hCWd9BxzdvRgeMRr123zZ3EmKDSy8X**ZiGf
uQyXlA9cOqpCxdQLj2zXv5VHrOdlsA**1UAGprwhYrxOz/**v3xQ7b2nXusRoZRfDlts
iadvWx5DhLEb2+**uVl9geteeymLIVUTzm8WnUITEE7by2**HAQf9VlT9CrQSVQ21wLC
hvmk47Nt8WIGyPwRh1qOhvIXLDLxD9**rkBSC1G01RhzwvctDy88Tmt2Ut47ZR**EScP
YUz/bf/qxITzX2L7tE35s2w+**RUIFIFc4nJa3Xhp0wMoTAz5UYMiWIc**XZ38qfGlY=
=PJTS
-----END PGP SIGNATURE-----
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet
