Re: Can Shapes always be Classes?

On 11/19/14 5:12 PM, Holger Knublauch wrote:
> Forgive my ignorance but isn't Dublic Core Elements just a collection of
> properties? And those properties have no rdfs:domain, which means they
> can be attached to anything.

Or to nothing. There are many who use DCE on its own for description of 
resources, adding no constraints. At the moment that metadata tends to 
be exposed as JSON, but as we move more toward RDF,it could also be 
exposed in RDF with a simple transformation. As it has been developed 
without constraints or classes, I would expect this to look like:

<URI>
   dce:title "something" ;
   dce:creator "something" ;
   dce:publisher "something .

Any clue as to constraints will not be in the instance data, but in a 
backend application whose rules could possibly exported as what DCMI 
calls an "application profile" - a set of rules that are separate from 
the instance data.

The advantage of this, btw, is that one can massively aggregate data 
from these hundreds of systems without running into conflicts between 
constraints. This is something that is commonly done in the cultural 
heritage world, and that is already done with the non-RDF data coming 
from these systems. What you get is imprecise but mashable (something 
that I think RDF OW suports).

  But any class can add constraints on how
> these DC properties shall be used, e.g. to indicate that dc:author must
> be present and an xsd:string. But that topic feels unrelated to the
> rdf:type discussion.

It's related because it represents a case where a vocabulary is not 
organized around classes. I know of two other vocabularies, not yet in 
use but potentially important: #1 only provides 5-6 classes for over 900 
properties; #2 defines no classes at all and have about 800 properties. 
I'm not prepared to make assumptions about how the instance data will 
look, but I can say that there is a huge range in how people approach 
vocabulary design and the instance data that will be produced. There's 
another vocabulary in progress that is proposing a class with about 
200-300 subclasses in order to handle the great variety of kinds of 
creators that are recognized in library and archive data - all of which 
need to be validated. (I will write these up as use cases, but at the 
moment do not have access to the wiki.)

The upshot is that if validation is based on class membership, then we 
need to look at a wide variety of data -- especially data that did not 
specifically design its classes as validation points.

kc

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

Received on Thursday, 20 November 2014 16:37:01 UTC