+1 (I was actually starting to write the same)
We precisely asked Thomas to implement a special Dublin Core category
http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=requirements/dc-requirements
so that it wouldn't be polluted by the other RDF-validation case he has already added to the database ;-)
One thing I'm a bit puzzled is the 'stories' Eric is suggesting. To me this should be in the 'use cases'
http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=use-cases/dc-use-cases
or the more application-specific 'case studies'
http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=case-studies/dc-case-studies
Actually I was a bit unhappy about some 'use cases', which are really close to the requirements, at least in wording. But well we are still working on them (and yes I remember I have an action to react to the email Stefanie has just sent...)
Cheers,
Antoine
On 9/12/14 9:38 AM, Bosch, Thomas wrote:
> Hi Eric,
>
> when I started to record RDF validation requirements from the W3C RDF Validation workshop in 2013
> my intention and vision was to have one system which could be used to manage all RDF validation requirements as well as associated use cases, case studies, and tools which are relevant for different domains.
>
> In order to support different views on requirements, use cases, and case studies for multiple domains like DC I introduced views like
> - DC case studies: http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=case-studies/dc-case-studies
> - DC use cases: http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=use-cases/dc-use-cases
> - DC requirements: http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=requirements/dc-requirements
>
> As a consequence each domain can browse the requirements, use cases, and case studies the domain is interested in, but also requirements, use cases, and case studies from other domains.
>
> I would appreciate if you and other W3C RDF data shapes members would use this requirements database (http://purl.org/net/rdf-validation)
> in order to record more RDF validation requirements, use cases, and case studies.
>
>
> Cheers,
> Thomas
>
> --
> Thomas Bosch, M.Sc. (TUM)
> PhD Student
> GESIS - Leibniz Institute for the Social Sciences
> Social Science Metadata Standards
> Visitors Address: B2,1, D-68159 Mannheim
> Postal Address: P.O.Box 12 21 55, D-68072 Mannheim
> Tel: + 49 (0) 621 / 1246-271
> Fax: + 49 (0) 621 / 1246-100
> Web: http://www.gesis.org
> Website: http://boschthomas.blogspot.com/
> GitHub: https://github.com/boschthomas/PhD
>
>
> ________________________________________
> Von: DCMI Architecture Forum [[log in to unmask]]" im Auftrag von "Eric Prud'hommeaux [[log in to unmask]]
> Gesendet: Freitag, 12. September 2014 10:17
> An: [log in to unmask]
> Betreff: alien requirements for DCAP
>
> http://lelystad.informatik.uni-mannheim.de/rdf-validation/ is an
> excellent aggregation point and I'd like a sense from the community if
> aggretating still more use cases and requirements from other domains
> would be "worth the noise". In particular, how would y'all feel if
> there were stories like this attached to reqs?:
> [[
> R-2.72 dereferencable value sets
>
> A clinic performing a trial has a data entry program which tests each
> input value against a remote terminology hierarchy.
>
> R-3.14 query-able value sets
>
> A clinical value set is impractical to ship over the wire so the
> validator ships tuples of input value and value set identifier to a
> remote service.
> ]]
>
> If that doesn't seem so bad, how would you feel about 50? I ask
> because there are lots of folks who have thought about requirements
> for RDF validation but don't have a place to write them down. We can
> create a wiki for this, but then we'd have two lists. We can use yours
> but then you end up with all this extra stuff from another domain.
> The latter is better for me. Which is better for you?
> --
> -ericP
>
> office: +1.617.599.3509
> mobile: +33.6.80.80.35.59
>
> ([log in to unmask])
> Feel free to forward this message to any list for any purpose other than
> email address distribution.
>
> There are subtle nuances encoded in font variation and clever layout
> which can only be seen by printing this message on high-clay paper.
>
|