Re: Returning to OWL and application profiles

Many interesting replies here...

Based on the discussions here, what I'd like to see is a straightforward
RDF graph constraint language, operating under one simple assumption:

* The RDF graph is tree-like, with a single root. This seems to cover
most of the linked data examples as well as examples from Dublin Core

For example, an AP covering the case:

myrepo:im123 rdf:type dct:Image,
             dct:creator [                          # a single creator
                rdf:type dct:Agent,                 # always Agent
                foaf:name "Ralph Johnson"] .        # single string name
             dct:language [                         # a single language
                rdf:type dct:LinguisticSystem,      # always same type
                rdfs:label "en" ] .                 # en, fr or de
             dct:subject <http://example.org/subjects/a> .  # optional subject, a b or c.

could be described in XML like so:

<?xml version='1.0' encoding='UTF-8' ?>

<ap:profile xmlns:ap='http://dublincore.org/dc-ap/xml'
  xmlns:dct='http://purl.org/dc/terms/'
  xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
  xmlns:foaf='http://xmlns.com/foaf/0.1/'>

  <ap:property="rdf:type" ap:uri="http://purl.org/dc/terms/Image" ap:minOccurs="1" ap:maxOccurs="1"/>
  <ap:property="dct:creator" ap:minOccurs="1">
    <ap:property="rdf:type" ap:uri="http://purl.org/dc/terms/Agent" ap:minOccurs="1" ap:maxOccurs="1"/>
    <ap:property="foaf:name" ap:nodeType="PlainLiteral" />
  </ap:property>
  <ap:property="dct:language" ap:minOccurs="1" ap:maxOccurs="1">
    <ap:property="rdf:type" ap:uri="http://purl.org/dc/terms/LinguisticSystem" ap:minOccurs="1" ap:maxOccurs="1"/>
    <ap:property="rdfs:label" ap:nodeType="PlainLiteral" ap:minOccurs="1" ap:maxOccurs="1">
      <ap:oneOf>
        <ap:alt>en</ap:alt>
        <ap:alt>fr</ap:alt>
        <ap:alt>de</ap:alt>
      </ap:oneOf>
    </rdfs:label>
  </ap:property>
  <ap:property="dct:subject" ap:nodeType="URI" ap:minOccurs="0" ap:maxOccurs="1">
    <ap:oneOf>
       <ap:alt>http://example.org/subjects/a</ap:alt>
       <ap:alt>http://example.org/subjects/b</ap:alt>
       <ap:alt>http://example.org/subjects/c</ap:alt>
    </ap:oneOf>
  </ap:property>
</ap:profile>

And this in turn could be mapped to XML Schema for a normalized XML
serialization, or alternatively implemented using SPARQL or whatever
technology preferred.

The above is along the lines of Alistair's proof-of-concept Graph-ML.

Using the above method, the AP is completely decoupled from the
semantics, and acts as pure pattern matcher.

One could imagine semantic extensions, for example by only allowing
instances of a certain class as values of a property.

  <ap:property="dct:subject" ap:nodeType="URI" ap:minOccurs="0" ap:maxOccurs="1">
    <ap:instanceOf ap:resource="http://example.org/subjectClass" />
  </ap:property>

or even limiting values to resources matching a certain pattern, 

  <ap:property="dct:subject" ap:nodeType="URI" ap:minOccurs="0" ap:maxOccurs="1">
    <ap:match>
      <ap:property="skos:inScheme" ap:URI="http://example.org/subjectScheme"/>
    </ap:match>
  </ap:property>

such a construct would then match external data (from a vocabulary), not
triples in the metadata record.

Something like the above would be quite a valuable addition to the RDF
set of specs, IMHO.

/Mikael 

tis 2010-10-12 klockan 13:11 +0200 skrev Antoine Isaac:
> Hi Mikael,
> 
> Thanks for starting this interesting thread :-)
> 
> 
> > I'm in the middle of finalizing my thesis on metadata interoperability
> > and harmonization, and I'm right now formulating a section on RDF and
> > application profiles, so the discussion I saw here comes at an
> > interesting time for me :-)
> >
> > The issue from my point of view with using OWL for defining RDF
> > application profiles, is that APs define domain-specific structural
> > constraints while OWL adds semantics to existing classes.
> >
> > I.e. if I produce an OWL-based AP saying that the cardinality of
> > dc:title is exactly 1, for a specific class, and someone else produces
> > an OWL-based AP saying that the cardinality is 2 for the same class, the
> > result is a *contradiction*.
> 
> 
> Well, I have what I think is a quite traditional SW background, and I'd be tempted to turn the argument the other way round ;-)
> If the instances of one class in an AP have one title and the instances of that class in another AP have two titles, then it is perhaps that these two APs are thinking of two different classes, really. Possibly they could be two subclasses of a common superclass, but two different classes, still.
> I think this is quite in line with Jeff's message suggesting you could do things like this
> baz:Widget rdfs:subClassOf foo:Widget.
> to make the commitment of your various APs a bit clearer.
> 
> I'm also a bit puzzled by your "APs define domain-specific structural constraints while OWL adds semantics to existing classes." Again, I am pretty new to the APs as practiced in the DC realm, but why wouldn't you consider classes (and APs built on top of them) from a (SW) semantic perspective?
> I understand that OWL and RDF will fail for arrangement/presentation of data (order of XML elements, e.g.), which is not really about semantics. But to me--and to many in the SW community--cardinality belongs to semantics of classes and properties.
> 
> 
> > This differs substantially from the case with application profiles,
> > where the cardinality is not seen as part of the semantics of a class,
> > but rather part of a set of restrictions, external to and independent of
> > the class. Multiple incompatible application profiles are perfectly
> > normal.
> >
> > Therefore, publishing an OWL ontology defining domain-specific semantics
> > for certain classes or properties is just as bad practice as if someone
> > produces an RDF Schema saying the range of dct:creator is
> > myorg:Employee. This defines new semantics of dct:creator, something
> > that is simply not true, and can cause involuntary contradictions.
> >
> > The other issue is the open world assumption that I saw Pete mention,
> > i.e. the fact that if an OWL ontology specifies a cardinality of 2 for
> > dc:title, and only one is found, this results in the generation of a new
> > dc:title statement, not in non-validity of the record.
> >
> > Thus, we would need an alternative semantics for OWL to perform
> > validation.
> 
> 
> Point taken. But even then I can still play the devil's advocate. What in a pure XML world I decide to create something like
> <dc:title>a title<dc:title>
> <dc:title><dc:title>
> ?
> By saying that the cardinality for dc:title is 2, it seems that you overlook some info on your model (or AP). That these titles should not be empty or unknown, for example. And taking it properly into account may require some more subtle axioms/specs, both in traditional XML and with Semantic Web languages. Note that it could be that OWL(2) is not enough for all your constraints. But there could be some complementary checking mechanisms (using SPARQL queries is an obvious candidate, but there could be others) which would help you perform validation without changing the semantics.
> 
> 
> > But that's exactly it - the semantics is "alternative" and on its face,
> > the semantics of the published OWL file is something else entirely.
> >
> > As a concrete example, if I serve an OWL file from my web server, using
> > application/rdf+xml as suggested by the OWL specs [1], the
> > interpretation will be as RDF triples using the RDF and OWL built-in
> > semantics, thus resulting in the generation of new triples, potentially
> > contradiction with other ontologies, and not in validation as expected.
> 
> 
> Well, contradiction (aka inconsistency) is what is used for data validation in the RDF/OWL world. So if we can detect contraditions I wouldn't be unhappy, at least from the perspective of us able to validate some data :-)
> 
> 
> > What *would* work is using application profile specific classes for each
> > separate OWL-based AP, and only constraining them, but that might appear
> > a bit cludgy.
> 
> 
> Or forcing you to make explicit the hidden assumptions of your profile...
> 
> It's really a situation where the cons for an OWL approach (and being awkward to manipulate is not the least default OWL has, sure) could be balanced by some strong pros, and we should not discard them too quickly!
> 
> Cheers,
> 
> Antoine
> 
> 
> >
> > So, I'm a bit unsure regarding using non-standard semantics of OWL. I
> > don't really see a clean solution at the moment.
> >
> > /Mikael
> >
> > [1] http://www.w3.org/TR/owl-ref/#MIMEType
> >
> >
> >
>

Received on Tuesday, 12 October 2010 19:53:08 UTC