Re: Can Shapes always be Classes?

On 11/4/14 9:16 PM, Holger Knublauch wrote:
> I believe there is a fundamental difference in how the various proposals
> treat the relationship between resources and their shapes:
>
> - In OWL and SPIN, constraints are attached to classes. rdf:type triples
> are used to determine which constraints need to be evaluated for a given
> instance.
>

With little effort, I was able to find data sets from the Linked Open 
Vocabularies that either 1) do not use classes at all or 2) do not use 
rdf:type triples. These are just a sample (each is a single example):

http://eprints.soton.ac.uk/cgi/export/eprint/272587/RDFXML/eps-eprint-272587.rdf
http://datahub.io/dataset/sweto-dblp.rdf
http://dati.camera.it/ocd/data/persona.rdf/p305757?output=xml
http://www.dbpedialite.org/things/52780.rdf

Also note that Europeana, one of the larger cultural heritage datasets, 
uses the class designation form:

<edm:WebResource rdf:about="http://content.staatsbibliothek......

for all classes.

kc




> - In the original Resource Shapes and ShEx, Shapes are stand-alone
> entities that may or may not be associated with a class. Other
> mechanisms than rdf:type are used to point from instances to their shapes.
>
> I believe the main motivation for the latter design are the User Stories
> S7 and S8: different shapes at different times, and properties can
> change as they pass through the workflow. I would like to learn more
> about this and have specific examples that we can evaluate.
>
> My current assumption is that these scenarios can be expressed via named
> graphs, so that different class definitions are used in different
> contexts. Which graph to use would be specified in some kind of header
> metadata or via a special property (e.g. owl:imports). Alternatively,
> different classes could be used, just like different shapes are used
> depending on the context. I argue that using rdf:type and RDFS classes
> is a well-established mechanism that we should try to build upon. What
> problems do the proponents of the decoupling see with those ideas?
>
> I think this is a major design decision that we need to clarify early.
> Instead of excluding those scenarios, I would like to accommodate them
> without having to introduce completely new mechanisms.
>
> Thanks
> Holger
>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Wednesday, 19 November 2014 15:06:17 UTC