Hi,
yes, as we have use cases for matching shapes and for class assignments (rdf:type) we should definitely offer both validation entry points.
And this is easy implementable in SPIN.
Best,
Thomas
Thanks, Thomas, for this analysis. The one thing that I think we will
need to add is the ability to define constraints in relation to rdf:type
declarations. For example, in EDM, there is a rule that for each
edm:ProvidedCHO there must be one ore:Aggregation. Then the required
properties are within the context of ProvidedCHO and Aggregation. I
think that the DSP description template serves this function, but is not
based around an rdf:type. Making that a type-based unit shouldn't be too
difficult. The current rules for applying DSPs (in section 3 of the
document) make the connection between the DSP and the graph based on the
pattern of the statements. This has problems because missing statements,
or added statements, can cause a graph not to match the pattern in the
DSP. There are cases where matching on patterns is fine, but others
require a type.
kc
On 1/6/15 2:50 AM, Bosch, Thomas wrote:
> Hi,
>
> I also think it is worth to have a DSP core covering the majority of our use cases.
> The new DSP can be mapped to whatever the W3C develops as language.
>
> I made a quick evaluation of BIBFRAME regarding our mentioned requirements:
>
> simple cardinality is covered by BIBFRAME:
>
> "propertyTemplate": [
> { ... },
> {
> "propertyURI": "http://bibframe.org/vocab/titleStatement",
> "propertyLabel": "Title",
> "mandatory": "true",
> "repeatable": "true",
> "type": "literal"
> },
> { ... }
> ]
>
> allowed values are not covered by BIBFRAME
> allowedValues may be introduced for valueConstraints as follows:
>
> "propertyTemplates": [
> { ... },
> {
> "propertyURI": "http://bibframe.org/vocab/subject",
> "propertyLabel": "Subject",
> "type": "resource",
> "valueConstraint": {
> "allowedValues": [ "value 1","value 2","value 3" ]
> }
> },
> { ... }
> ]
>
> valid datatypes may be covered by BIBFRAME as this is an implementation issue.
> You can state constraints on datatypes for literals in BIBFRAME:
>
> "propertyTemplates": [
> { ... },
> {
> "propertyURI": "http://bibframe.org/vocab/vra/beginDate",
> "propertyLabel": "Begin Date",
> "type": "literal",
> "valueConstraint": {
> "valueDataType": {
> "dataTypeURI": "http://bibframe.org/vocab/proposed/ISO8601",
> "dataTypeLabel": "ISO 8601",
> "dataTypeLabelHint": "ISO"
> }
> }
> },
> { ... }
> ]
>
> What is needed here is to implement to check for each datatype if the literal is valid.
> Regular expressions may be used here in the background when SPARQL is used for the actual implementation.
>
> property/class grouping (e.g. propertyX is used for classY) is covered by BIBFRAME, as property templates are referenced within resource templates:
>
> "resourceTemplate": [
> {
> "id": "bfp:Work:Book",
> "resourceLabel": "Book",
> "resourceURI": "http://bibframe.org/vocab/Text",
> "propertyTemplates": [
> { ... }
> ]
> }
>
>
> Cheers,
> Thomas
>
>
> So as not to take up time on the call tomorrow, and also to reach a
> wider group, here is my update on the W3C work:
>
> W3C has also been on hiatus during the holidays, but the meetings resume
> on Thursday. They meet weekly. There will also be a face-to-face meeting
> mid-February in Boston. (I will be there.)
>
> My guess as to what will transpire over the next months (and it is a
> guess) is that W3C will develop a fairly technical, detailed spec for
> validation. Because it will be technical and detailed, this is going to
> take some time. They will probably not address a user interface for the
> validation, although there are some members of the group for whom this
> is a priority. I suspect that will be offered outside of the W3C process
> by some.
>
> I think that we can assume that the details of the rules for validation
> will be covered by W3C. I also think that we can assume that the spec
> will be more detailed than what our community generally needs. This
> means that there could be room for the development of a user view to a
> core of requirements. In my opinion, a lot could be accomplished with
> just a few requirements:
>
> - simple cardinality (mandatory/optional, repeatable/not-)
> - value checking (allowed values, valid data-types)
> - property/class grouping (e.g. propertyX is used for classY)
>
> The DSP covers this and more. We might want to consider a "DSP-core"
> that hides some of the "more". I think it's worth looking at the
> BIBFRAME profiles [1].
>
> Something the DSP doesn't do but that will be prominent in the W3C work
> is tying validation to rdf:type declarations. DSP has resourceClass but
> not as a focus for validation. I think we should look at that.
>
> kc
> [1] http://www.loc.gov/bibframe/docs/bibframe-profiles.html
>
>
> --
> Karen Coyle
> [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
|