W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > July 2014

Re: ShEx relation to SPIN/OWL

From: Arthur Ryman <ryman@ca.ibm.com>
Date: Thu, 31 Jul 2014 16:06:37 -0400
To: "Peter F. Patel-Schneider" <Peter.Patel-Schneider@nuance.com>
Cc: <public-rdf-shapes@w3.org>
Message-ID: <OFB91A7953.C97BDE2B-ON85257D26.006B6CCA-85257D26.006E7961@ca.ibm.com>
Peter,

Apologies for the delayed reply.

The reason I say RDFS and OWL fail when combining terms from multiple 
sources is that the constraints associated with a term often depend on how 
the term is used in a particular application. Consider DC Terms. It was 
designed to provide a highly reusable vocabulary. There are very few 
constraints imposed by DC Terms and this makes it very reusable. For 
example, consider dcterms:title. In one application dcterms:title may be a 
required property while in another it may be optional. So where do you put 
those constraints? They do not belong in the DC Terms vocabulary. You need 
another place to define constraints and associate them with the 
application. That is what OSLC Shapes does.

So if you use RDFS and OWL, and include a lot of constraints, then the 
terms are not very reusable because they carry a lot of baggage in the 
form of inferences which may not make sense in your application. For 
example, if you used rdfs:domain or rdfs:range then you infer certain type 
triples. I once was looking for terms that defined start and stop dates. I 
found dtstart and dtend in http://www.w3.org/2002/12/cal/ical but when I 
looked at the RDFS/OWL it had a lot of undesired inferences concerning the 
domain. So if I had reused dtstart in my application, then a reasoner 
would have inferred a lot of triples that didn't make sense.

At OSLC we are trying to integrate information from a lot of applications. 
We try to reuse terms from established vocabularies. We define new common 
terms in a core OSLC vocabulary. We do this to make writing queries 
easier. This means that resources contain terms from many vocabularies.

To make an analogy with natural language, we have words and they are 
defined in a dictionary. We also have grammars and they define how the 
words are combined. We have the general rules of grammar for ordinary 
prose. We also have other types of grammars for specialized texts such as 
poetry. There are rules for sonnets, limericks, etc. The dictionary is 
analogous to the RDFS or OWL document. The grammar is analogous to a Shape 
document.

Regards, 
___________________________________________________________________________
Arthur Ryman, PhD

Chief Data Officer, Rational
Chief Architect, Portfolio & Strategy Management
Distinguished Engineer | Master Inventor | Academy of Technology

Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:   "Peter F. Patel-Schneider" <Peter.Patel-Schneider@nuance.com>
To:     <public-rdf-shapes@w3.org>, 
Date:   07/10/2014 10:05 AM
Subject:        Re: ShEx relation to SPIN/OWL



> From: Arthur Ryman <ryman@ca.ibm.com>
> Date: Thu, 3 Jul 2014 10:58:24 -0400
> To: "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
> Message-ID: 
<OFF14B15B5.802B33E2-ON85257D0A.004C62E1-85257D0A.005240FE@ca.ibm.com>
>
> I'd like to back up a little and discuss the need for something other 
than
> OWL and SPARQL.

[...]

> Another important requirement is that a constraint language should be
> independent of any vocabulary or ontology since it is often the case 
that
> an RDF document combines terms from multiple sources. Both OWL and RDFS
> fail on this count.

I believe that this is false.  Can you provide examples where OWL or RDFS 
fail 
on this count, particularly where the combination of multiple sources 
contributes to the failure?

[...]

> Regards,
> 
___________________________________________________________________________
> Arthur Ryman, PhD
>
> Chief Data Officer, Rational
> Chief Architect, Portfolio & Strategy Management
> Distinguished Engineer | Master Inventor | Academy of Technology
>
> Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)
>
>

peter
Received on Thursday, 31 July 2014 20:07:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:39 UTC