Re: Can Shapes always be Classes?

On 11/20/2014 10:05, Karen Coyle wrote:
>
>
> On 11/19/14 3:18 PM, Holger Knublauch wrote:
>> I am not sure what point you are trying to make here. The above means
>> that the resource has rdf:type edm:WebResource.
>
> Holger,
>
> Agreed that that's what it "means", but you keep saying: "rdf:type 
> triples" - which to me says:
>
> A rdf:type B (in RDF/XML)
> B a A  (in turtle)
>
> If instead you instead mean "typed subjects", then that expands what I 
> was understanding.

Let's make sure we don't confuse serialization syntax from actual 
triples. RDF/XML has many ways of stating the same, but what matters are 
the rdf:type triples in the graph (where rdf:type is the predicate and 
the subject resource on the left and a class on the right).

> (But doesn't convince me that this is one-to-one with shapes that need 
> validation.)
>
> So what I glean from this is that you are focused on types, except 
> those subjects typed by inferencing. Is that the case?

Yes, SPIN uses rdf:types as its preferred way of linking a resource with 
the constraints that it needs to fulfill. Basically, constraints then 
get associated with classes, which produces a natural way of 
partitioning and organizing the constraints, IMHO better than having 
free-floating Shapes that mirror the class hierarchy.

Inferencing is another topic - if you have some server that produces RDF 
under the assumption that the recipient will perform inferencing to get 
the missing triples then this will need to be executed before running 
constraint checks. How and whether this topic gets handled by this WG 
remains to be seen.

>
> Perhaps we can then clarify exactly what falls under "rdf:type 
> triples" -- and what doesn't.

See above, not sure where the confusion is.

> And whether untyped data, such as Dublin Core Elements 1.1 in RDF, has 
> a fallback to rdf:Resource.

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. 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.

Sorry we may be talking about different things, maybe others can join 
the discussion to moderate.

Thanks,
Holger

Received on Thursday, 20 November 2014 01:15:26 UTC