Hi Thomas,
That sounds good enough for now. The process of assigning manually the requirements category ‘Dublin Core requirements’ to the requirements seems error-prone, compared to a dynamic view which would have extracted the good requirements from the path between requirements and (DC) case studies via use cases. But I believe it will be alright.
Also, I think I would like to have the other categories on the left customizable so that they would show only DC requirements too. Perhaps by sending Drupla two query parameters instead of one (e.g. ?q=taxonomy/term/5 and ?q=requirements/dc-requirements).
But I guess all this is probably a sign that I should ask an RDF dump and playwith a SPARQL query engine for myself ;-)
Let's focus first on extracting these requirements, from our cases.
Thanks a lot!
Antoine
On 7/28/14 8:54 PM, Bosch, Thomas wrote:
> Or just click on the left sidebar on the corresponding requirements class 'Dublin Core Requirements'...
>
> --
> 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 Bosch, Thomas
> Gesendet: Montag, 28. Juli 2014 20:53
> An: [log in to unmask]
> Betreff: AW: Dublin Core requirements
>
> Hi Karen,
>
> I browsed the current DC use cases and assigned all associated requirements to the class of requirements 'Dublin Core Requirements'.
>
> If you click on this view http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=requirements/dc-requirements
> you will see all the requirements which are relevant for this community.
>
> DC requirements have to be assigned to the requirements class 'Dublin Core Requirements' in order to be showed in this view.
>
>
> 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
> 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: Montag, 28. Juli 2014 19:43
> An: [log in to unmask]
> Betreff: Re: Dublin Core requirements
>
> Thomas, it probably is helpful, but it will be clearer when it's with
> real data, not just "test-1". ;-) Does this mean, though, that the
> current requirements need to be re-coded for this data?
>
> kc
>
> On 7/28/14, 9:15 AM, Bosch, Thomas wrote:
>> Hi,
>>
>> I added another view on requirements:
>>
>> http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=requirements/dc-requirements
>>
>> On this site, all requirements are listed which are assigned to the
>> requirements category ‘Dublin Core requirements’.
>>
>> (So far, only test requirements are assigned…)
>>
>> Is this view helpful?
>>
>> Thanks,
>>
>> 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:[log in to unmask]]
>> *Im Auftrag von *Eric Prud'hommeaux
>> *Gesendet:* Sonntag, 27. Juli 2014 14:04
>> *An:* [log in to unmask]
>> *Betreff:* Re: AW: AW: OWL is hard?
>>
>>
>> On Jul 27, 2014 12:31 PM, "Antoine Isaac" <[log in to unmask]
>> <mailto:[log in to unmask]>> wrote:
>> >
>> > Hi Thomas,
>> >
>> >
>> >
>> >> One possibility would be to have an additional category in the left
>> sidebar 'Dublin Core Requirements' (I added it already, but can delete
>> it if not wished).
>> >> That would be the fastest and easiest solution.
>> >
>> >
>> >
>> > Yes.
>>
>> This is good for several reasons:
>>
>> You can track evolving ideas on the Shapes list.
>>
>> The W3C process can leverage your diligence.
>>
>> You can exercise your editorial power to provide humorous labels for
>> the foreign input.
>>
>> It's a win all around (except that you end up doing a lot of work). Many
>> thanks.
>>
>> >> I can also add an additional view on requirements which are only
>> associated with the requirements class 'Dublin Core Requirements'.
>> >> This view could be accessed with an additional sub-menu entry
>> 'Dublin Core Requirements' (or something similar) under the requirements
>> main menu entry.
>> >>
>> >
>> >
>> > It sounds good, but inf act I'm not sure I can see what the end
>> result (UI) would be!
>> >
>> > Cheers,
>> >
>> > Antoine
>> >
>> >
>> > On 7/27/14 12:10 PM, Bosch, Thomas wrote:
>> >
>> >>
>> >> --
>> >> 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: Bosch, Thomas
>> >> Gesendet: Sonntag, 27. Juli 2014 12:04
>> >> An: DCMI Architecture Forum
>> >> Betreff: AW: AW: OWL is hard?
>> >>
>> >> Hi Antoine,
>> >>
>> >> I see your point.
>> >>
>> >> One possibility would be to have an additional category in the left
>> sidebar 'Dublin Core Requirements' (I added it already, but can delete
>> it if not wished).
>> >> That would be the fastest and easiest solution.
>> >>
>> >> Is this solution what you expected?
>> >> Dies this fit your requirement?
>> >>
>> >>
>> >> Best regards,
>> >> Thomas
>> >>
>> >>
>> >> Hi Thomas,
>> >>
>> >> This makes me think about a potential feature to consider for the
>> database. Can we had something to distinguish between the requirements
>> that are originated from the DC task group work from the ones discussed
>> on the W3C list?
>> >>
>> >> I know that the link between cases and requirements allow us to find
>> the list of "Dublin Core" requirements. But there is no shortcut to get
>> requirements that are connected to all DC cases, in one go. [1]
>> >>
>> >> Why am I asking this? Honestly, I find that what is happening on the
>> W3C list is really good to stimulate people around the creation of the
>> work. But from a design process perspective, it's a real nightmare. All
>> these emails are fired with no grounding on real cases (I'm not saying
>> they're not legit, just that there is no explicit relation with real cases).
>> >>
>> >> I'd like our work in the task group not to be polluted by this. If
>> you can entertain the noise, that's great. But I don't have the time,
>> and I suppose many people on the DC task group won't have either.
>> >>
>> >> Besides, if the W3C group starts, the requirements will probably be
>> tracked through a W3C issue system. And those issues will probably be
>> quite strictly controlled, i.e. only approved requirements connected to
>> use cases will be kept there. I would regard this as a good practice for
>> us too.
>> >>
>> >> Again, I'm not requesting that you wouldn't introduce the W3C list
>> requirements in your DB. You created it, it would be unfair for us to
>> dictate its use. What I'd like is that at any moment we can say 'ok,
>> this is our curated data, and this is the explorative stuff from
>> others'. If we can't do it, I'm afraid the DB won't be usable by the group.
>> >>
>> >> Cheers,
>> >>
>> >> Antoine
>> >>
>> >> [1] I believe there must be a way to get a requirement listing it
>> quite easily.
>> >> What I'm wondering is whether this can be applied to the facets on
>> the left menu. I believe these need to work on the entire requirement
>> database.
>> >>
>> >> On 7/27/14 10:31 AM, Bosch, Thomas wrote:
>> >>>
>> >>> Hi Simon,
>> >>>
>> >>> I added this requirement to the RDF validation requirements db:
>> >>>
>> http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=R-190-SPECIFY-EXPECTED-BEHAVIOR-UNDER-ALL-POSSIBLE-ENTAILMENT-REGIMES
>> >>>
>> >>>
>> >>> Kind regards,
>> >>> 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:* Simon Spero [[log in to unmask] <mailto:[log in to unmask]>]
>> >>> *Gesendet:* Freitag, 25. Juli 2014 22:43
>> >>> *An:* Kendall Clark
>> >>> *Cc:* [log in to unmask] <mailto:[log in to unmask]>
>> >>> *Betreff:* Re: OWL is hard?
>> >>>
>> >>> On Fri, Jul 25, 2014 at 1:46 PM, Kendall Clark
>> <[log in to unmask] <mailto:[log in to unmask]>
>> <mailto:[log in to unmask] <mailto:[log in to unmask]>>> wrote:
>> >>>
>> >>>
>> >>> foaf:Person class,
>> >>> foaf:name 1 1,
>> >>> foo:email 1 1,
>> >>> foo:phone 0 * .
>> >>>
>> >>> Some Manchester syntax (again corrections welcome)
>> >>>
>> >>> Class: foaf:[P]erson
>> >>> foaf:name exactly 1
>> >>> foo:email exactly 1
>> >>> foo:phone min 0
>> >>>
>> >>>
>> >>> I'm not sure exactly what constraint is being specified on on
>> foo:phone in the original example.
>> >>>
>> >>> The informal description is about a web service which requires
>> that "all resources submitted to it must be of type foaf:Person, must
>> have a foaf:name and a foo:email, and possibly one or more foo:phone".
>> >>>
>> >>> a) If the intended meaning of the final clause is that the
>> cardinality of foo:phone is between 0 and infinity, then it is trivial.
>> >>>
>> >>> b) If the intended meaning of the final clause is to serve purely
>> as documentation then it is not really a constraint.
>> >>>
>> >>> c) If the intended meaning of the entire phrase is that it is to be
>> construed using /expressio unius
>> <http://en.wikipedia.org/wiki/Statutory_interpretation#Textual>/, then
>> the final clause /is/ necessary, because any predicates not explicitly
>> mentioned are forbidden. Under this interpretation,
>> >>>
>> >>> Example 1 is valid:
>> >>> 1)
>> >>>
>> >>> [ a foaf:Person ;
>> >>>
>> >>> foaf:name "John F. Manning" ;
>> >>>
>> >>> foo:email
>> "[log in to unmask]
>> <mailto:[log in to unmask]>
>> <mailto:[log in to unmask]
>> <mailto:[log in to unmask]>>";
>> >>> ].
>> >>>
>> >>> But:
>> >>>
>> >>> *2)
>> >>>
>> >>> [ a foaf:Person,foaf:Agent ;
>> >>>
>> >>> foaf:name "John F. Manning" ;
>> >>>
>> >>> foo:email
>> "mailto:[log in to unmask]
>> <mailto:[log in to unmask]>
>> <mailto:[log in to unmask]
>> <mailto:[log in to unmask]>>";
>> >>> ].
>> >>>
>> >>> ... is invalid, because it includes a value for rdf:type even
>> though that value is entailed by the foaf Ontology.
>> >>> A similar problem could occur if there were sub or
>> super-properties of foo:email - e.g. if there were sub properties for
>> officialEmail and personalEmail, or if there were a super property
>> contactURL.
>> >>>
>> >>> Also:
>> >>> *3)
>> >>>
>> >>> [ a foaf:Person ;
>> >>>
>> >>> foaf:name "John F. Manning" ;
>> >>>
>> >>> foo:email
>> "[log in to unmask]
>> <mailto:[log in to unmask]>
>> <mailto:[log in to unmask]
>> <mailto:[log in to unmask]>>";
>> >>>
>> >>> foaf:gender "male";
>> >>>
>> >>> ].
>> >>>
>> >>> ... is invalid, because foaf:gender is not explicitly mentioned.
>> >>>
>> >>> Any specification that implements this approach must specify
>> expected behavior under all possible entailment regimes.
>> >>>
>> >>> I am not sure if it is possible to specify in OWL the constraint
>> that the maximum cardinality for all properties apart from a
>> specifically mentioned set is 0 (it is probably doable in SPARQL as
>> long as entailment regimes are handled carefully).
>> >>>
>> >>> It would not be too hard to define OWL constructs that could serve
>> this purpose if the CWA is in effect- e.g. pseudo-properties like
>> 'otherObjectProperties' and 'otherDataProperties', or even
>> 'otherProperties'. This kind of pseudo-property would probably not be
>> suitable for use in inferencing.
>> >>>
>> >>> Simon
>>
>
|