In the database we could either use the description field to specify synonyms or I could add a new field 'synonyms' which may also have multiple values.
The most important thing is to have this documented.
--
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
> -----Ursprüngliche Nachricht-----
> Von: DCMI Architecture Forum [mailto:[log in to unmask]]
> Im Auftrag von Karen Coyle
> Gesendet: Dienstag, 22. Juli 2014 17:47
> An: [log in to unmask]
> Betreff: Re: Required/optional/repeatable vs. cardinality constraints Was: Re:
> AW: Database of Requirements on RDF Validation: http://purl.org/net/rdf-
> validation
>
> I agree with Adrian's technology, but since many people work with
> "required/optional" is there a way we can make these synonyms for those
> cardinality constraints?
>
> kc
>
> On 7/22/14, 2:49 AM, Adrian Pohl wrote:
> > Hello.
> >
> > On 21.07.2014 18:19, Bosch, Thomas wrote:
> >> Hi Evelyn, hi all,
> >>
> >> -Required Classes: so far, we do not have such a requirement
> >>
> >> -Non-repeatable Properties: so far, we do not have such a requirement
> >
> > Regarding required, optional, repeatable, non-repeatable properties:
> > Doesn't it suffice if you have a way to express minimum, exact and
> > maximum cardinality? IMO, if these cardinality requirements are
> > fulfilled you can describe - amongst others - the
> > required/optional/repeatable cases:
> >
> > - "required" is the same as minCardinality=1
> > - "optional" is the same as minCardinality=0
> > - "repeatable" can be expressed as a maxCardinality of >1 or not
> > defining a maximum cardinality at all.
> > - non-repeatable could be expressed with exactCardinality=1 or
> > maxCardinality=1.
> >
> > If I see this right, I guess it wouldn't make sense to adress
> > cardinality and required/optional/repeatable properties seperately in an
> > AP vocabulary. Thus, we might somehow structure these requirements in
> > the database to make it easier to maintain an overview.
> >
> > Adrian
> >
> >> -Non-repeatable Classes: What does this mean? Are you on the instance
> >> level? I.e. that there can be only (at most) one instance of a specific
> >> class in an RDF graph?
> >>
> >> -Properties that are not part of the model: do you mean something like
> >> 'disallowed properties'? Properties that should not be allowed to be
> >> stated in an RDF graph?
> >>
> >> Best,
> >>
> >> 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 <http://www.gesis.org/>
> >>
> >> Website: http://boschthomas.blogspot.com/
> >>
> >> GitHub: _https://github.com/boschthomas/PhD_
> >>
> >> *Von:*DCMI Architecture Forum [mailto:DC-
> [log in to unmask]]
> >> *Im Auftrag von *Evelyn Dröge
> >> *Gesendet:* Montag, 21. Juli 2014 16:03
> >> *An:* [log in to unmask]
> >> *Betreff:* Re: Database of Requirements on RDF Validation:
> >> http://purl.org/net/rdf-validation
> >>
> >> Hi Thomas, hi all,
> >>
> >> thank you again, Thomas and Kai, for creating the database. I think this
> >> is a good help to structure and compare our use cases!
> >>
> >> I have some direct questions which I would like to discuss with you and
> >> others that work with the database.
> >>
> >> I could not find suitable requirements for the following cases:
> >>
> >> - Required Classes (similar to R-68 Required Properties; could be
> >> connected to the use case for non-repeatable classes)
> >>
> >> - Non-repeatable Properties (opposite of R-70 Repeatable Properties; or
> >> can this requirement used for both?)
> >>
> >> - Non-repeatable Classes
> >>
> >> - Properties that are not part of the model (and should not be ingested,
> >> see UC-15)
> >>
> >> Do you have (or has anyone else) an idea how this could be linked to
> >> exisiting requirements? Otherwise I would suggest to expand the
> >> requirements collection.
> >>
> >> Another question: I have a case where I find it hard to distinguish
> >> between requirements. This relates to UC-24 (Property value match; EDM)
> >> and UC-9 (Wrong Mime Types in DM2E). Should these use cases be
> connected
> >> with R-37 or with R-92 (or both)?
> >>
> >> Thanks for your help!
> >>
> >> Best,
> >>
> >> Evelyn
> >>
> >> Am 17.07.2014, 13:00 Uhr, schrieb Bosch, Thomas
> <[log in to unmask]
> >> <mailto:[log in to unmask]>>:
> >>
> >> Hi all,
> >>
> >> I'm new to this mailing list and I would like to indoduce myself.
> >> My name is Thomas Bosch and I'm a PhD student in Computer Science in
> >> my fourth year now.
> >>
> >> I'm part of the editorial board of the DCMI RDF Application Profiles
> >> Task Group [1],
> >> whosepreliminary fields of work are (1) RDF Constraint Specification
> >> and Validation, (2) Definition of an RDF Application Profile, and
> >> (3) Request handling for RDF APs and data.
> >>
> >> Together with Kai Eckert (University of Mannheim), we created a
> >> database of requirements on RDF constraint formulation and
> >> validation, which is publicly accessable via
> >> http://purl.org/net/rdf-validation
> >> and extensible by the community.
> >>
> >> During the last half year, we identified more than 180 requirements
> >> on RDF validation.
> >> Sources have been (1) the 2013 W3C RDF Validation Workshop, (2) your
> >> valuable mailing list discussions, (3) the 2013 Semantic Web in
> >> Libraries conference,
> >> (4) discussions in the RDF Application Profiles Task Group, and (5)
> >> diverse research papers.
> >>
> >> The idea of this extensible database is
> >> (1) to collect and describe case studies from experts (from theory
> >> and practice dealing with RDF validation problems) and the general
> >> public,
> >> (2) to extract common use cases from these case studies that
> >> illustrate particular problems,
> >> (3) to specify requirements to be fulfilled in order to adequately
> >> solve these problems and meet the use cases,
> >> (4) to investigate existing best-practices regarding these
> >> requirements, and
> >> (5) to evaluate existing approaches / tools to which extend specific
> >> requirements are fulfilled.
> >>
> >> Using this approach, we try to structure the requirements
> >> engineering process for RDF validation.
> >> I see that there is currently a lot of discussion about requirements
> >> on RDF validation on this maling list, which I tried to capture in
> >> the requirements DB as well.
> >>
> >> The contributors of the DCMI RDF Application Profiles Task Group are
> >> currently adding further case studies, use cases, requirements, and
> >> relationships between these entities to the database.
> >> This should be a work done for and from the community dealing with
> >> RDF validation issues.
> >>
> >> The full source code of the system and the database with the current
> >> state of all requirements is also available:
> >> https://github.com/kaiec/reqbase
> >> You can easily set up a local version for own developments.
> >>
> >> Do you think this is the right way to go?
> >> Do you have further ideas?
> >>
> >> We hope this kind of contribution could be helpful for the community.
> >>
> >> Thank you very much and I really enjoy the valuable discussions on
> >> the mailing list
> >>
> >>
> >> Cheers,
> >> Thomas
> >>
> >> [1] http://wiki.dublincore.org/index.php/RDF-Application-Profiles
> >>
> >> --
> >>
> >> 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_
> >>
> >>
> >>
> >> --
> >>
> >> Evelyn Dröge
> >>
> >> Humboldt-Universität zu Berlin
> >> Berlin School of Library and Information Science
> >> - Digitised Manuscripts to Europeana (DM2E) -
> >> Sitz: Dorotheenstraße 26, D-10117 Berlin
> >> Post: Unter den Linden 6, D-10099 Berlin
> >> Tel.: +49 30 2093-4265
> >>
> >> [log in to unmask] <mailto:[log in to unmask]>
> >> www.ibi.hu-berlin.de <http://www.ibi.hu-berlin.de> | dm2e.eu
> >>
> >
>
> --
> Karen Coyle
> [log in to unmask] http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet
|