Hi Karen, hi Eric,
my comment also below...
> Thanks, Eric - comments inline - kc
> On 10/4/14, 9:33 PM, Eric Prud'hommeaux wrote:
> On Oct 4, 2014 9:47 PM, "Karen Coyle" <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
> >
> > I'm beginning to comb through the requirements that Stefanie and
> Evelyn provided, and I have a question about a requirement like:
> >
> > "Every cultural heritage object is described by using the classes
> edm:ProvidedCHO and ore:Aggregation."
> >
> > The documentation specifies that:
> >
> > "Exactly one instance of rdf:typeOf edm:ProvidedCHO and one instance
> of rdf:type ore:Aggregation. The property edm:aggregatedCHO (domain
> ore:Aggregation, range edm:ProvidedCHO) links them."
> >
> > This brings up for me a question that I've often asked and have
> gotten an interesting range of answers:
> >
> > What is the role of rdf:type when property domains also define the type?
>
> Our inferencing infrastructure focuses on type inference (perhaps if we
> were dogs we focus on smell instead) so Karen's question leads naturally
> to the role of inference in validation. I like a strategy where there is
> a sharp definition between the two. Most use cases appear to not require
> inference and those that do can be implemented as a pipeline of two
> operations. Following this strategy, validation can follow SPARQL's lead
> and not treat type differently from any other predicate.
>Which would mean that in order to validate types, one needs the rdf:type
>declaration, true? Otherwise, you have to infer the type. And I have
>seen SPARQL examples where rdf:type is quite useful, which is another
>reason to include it.
>
> > Is rdf:type optional?
>
> My goal with validation is to describe and verify the kind of data I've
> seen queried with SPARQL. It frequently has type arcs to clarify the
> intent of the data but it's rarely required in the data; SPARQL queries
> which process this data rarely include type arcs.
>
> When type is present, it rarely conveys the semantics which need to be
> validated. It may claim to be of type foaf:Person while its being
> validated as an IBM Almaden Rational Division research project leader in
> form twenty-seven B stroke six.
>I, too, have seen this in validation examples, yet it seems "foreign" to
>me from my bibliographic data viewpoint. I'm currently at a loss to
>explain why, except to say that the content of our data is less
>constrained than most business data, being primarily textual. We tend to
>validate the form/structure but not so much the content - other than to
>require that some data come from pre-composed vocabularies.
>
> They is a very interesting question. I suspect that may be an
> expectation, though whether it works on practice will need serious
> examination. My guess is that any machinery that allows you to validate
> resource A just on the basis of its type will be making universal
> assertions about FRBRer:Work which may be quite inappropriate in other
> contexts.
>
> Resource Shapes has a separate property to say that some node is
> expected to be of a particular shape.
>Yes, this is also what DSP does. I need to look back again at shapes,
>but what I suspect is that DSP has greater attention to the overall
>structure of a whole description (what we used to create as records)
>than ShEx, and less on the individual values. There definitely is
>nothing computational in the DSP (integer value must be >4 and <100, for
>example), which some business cases need. (Hmmm. We could use something
>of this nature for dates...)
This is the requirements / constraint R-45-RANGES-OF-RDF-LITERAL-VALUES
and can be formulated using OWL 2.
See these exmples: https://github.com/boschthomas/rdf-validation-requirements/tree/master/examples/R-45-RANGES-OF-RDF-LITERAL-VALUES
# constraints
# -----
:NumberPlayersPerWorldCupTeam
a rdfs:Datatype ;
owl:equivalentClass [
a rdfs:Datatype ;
owl:onDatatype xsd:nonNegativeInteger ;
owl:withRestrictions (
[ xsd:minInclusive "1"^^xsd:nonNegativeInteger ]
[ xsd:maxInclusive "23"^^xsd:nonNegativeInteger ] ) ] .
:position rdfs:range :NumberPlayersPerWorldCupTeam .
# invalid data
# -----
:MarioGoetze
:position "99"^^:NumberPlayersPerWorldCupTeam .
A new datatype is defined which is a restriction on the XML Schema datatype xsd:nonNegativeInteger.
The possible range of this dattype us restricted.
>Back to "type" - I can easily imagine many variations on type (in the
>RDF sense) which will make it hard to test. AFAIK, this is valid in RDF:
>:resourceA
> a foaf:Person ;
> a ore:Aggregate ;
> a edm:ProvidedCHO ;
> dct:creator :Karen .
>Valid, at least as long as none of those is declared disjoint from the
>others.
>In the open world, "type" is one of the more malleable qualities of the
>data. Anyone can "re-type" a resource by linking to it with a property
>of another type. ShEx shapes and DSP description templates seem to be of
>an entirely other "beast" -- structural rather than semantic: "node is
>expected to be of a particular shape".
>I still don't have an idea of how to create an accurate test for the EDM
>requirement. Others?
>kc
>
> > I'm trying to understand what functionality people see in requiring
> rdf:type so that we can make sure that functionality is covered in our
> AP work.
> >
> > --
> > Karen Coyle
> > [log in to unmask] <mailto:[log in to unmask]> http://kcoyle.net
> > m: 1-510-435-8234
> > skype: kcoylenet/+1-510-984-3600
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
|