RE: [oslc-core] Review of OSLC Core Vocabulary 3

["Jim Amsden" <jamsden@us.ibm.com>]

Jad,
Excellent questions. I'll attempt responses
imbedded below.


Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:      
 Jad El-Khoury <jad@kth.se>
To:      
 Jim Amsden/Raleigh/IBM@IBMUS
Cc:      
 "oslc-core@lists.oasis-open.org"
<oslc-core@lists.oasis-open.org>
Date:      
 02/11/2016 05:05 PM
Subject:    
   RE: [oslc-core]
Review of OSLC Core Vocabulary 3
Sent by:    
   <oslc-core@lists.oasis-open.org>

---

Hi
Jim & all,
 
So, I have a couple questions
that I still feels are left unanswered and I hope you can help me clarify.
As background, we want in
a project to define a company-specific domain vocabulary based on OSLC
Core, and also extend any existing OSLC specifications when necessary.
I am missing some guidelines
on how to go about defining a domain. Specifically I wonder about the following:
 
1.
I understood from your(Jim)
comments that a domain specification can reuse any Core Common Property,
and then simply override any of the constraints defined in OSLC Core. For
example, dcterms:creator be changed from the current Zero-or-many to Exactly-One.
Is there a risk in deviating
from OSLC Core?
Is there a need to highlight
in the specs if a certain constraint has been overridden, in order to keep
track of the changes?
Is there any aspect of the
common properties that a domain specs ought not to change?
<jra>OSLC domain specifications
are expected to be compatible instances of OSLC core with additional vocabulary,
shape constraints, and capabilities that are required for the domain. So
while an OSLC Domain specification could change a Core MAY clause to MUST,
it could or should not change a MUST to SHOULD or MAY. This would lead
to interoperability issues because clients and other servers would not
be able to predict what might be supported. 

Similarly, shape constraints
on core vocabulary should be consistent with the intended use of those
vocabulary items. Since the are all specified to be zero-or-many, domains
can safely specify exactly-one and not create any incompatibility issues.

The domain specifications
often do highlight their constraints on core in a section called Base Requirements.
The OSLC Change Management 3.0 spec provides a typical example: file:///Users/jamsden/Documents/workspace/oslc-ccm/specs/change-mgt/change-mgt.html#baseRequirements.
</jra>
 
2.
Any guidelines and/or templates
on how one ought to define a vocabulary? 
Specifically, when it comes
to defining constraints on a resource, I notice in the OSLC domain specifications
(and Core) that the properties tables are limited to the following constraints:
Occurs, read-only, value-type, Representation, Range & Description.
Is there a problem if a domain
specification chooses to define additional Property Constraints (such as
defaultValue) in the tables? 
I am afraid I might be confusing
the concepts of ResourceShapes and Vocabularies.
 
I suspect such issues are
trivial for an expert in linked data, but maybe not for someone with a
“closed-world” view (which I experience are most users of OSLC – including
myself). So, I wondering if such questions are worth detailing somewhere.
(Then I have something to refer to in my arguments J)
<jra>There are some
linked data best practices described here: https://jazz.net/wiki/bin/view/LinkedData/BestPractices.

Regarding the relationship
between vocabularies and shapes: OSLC domain vocabularies define the terms
(classes and properties) and their semantics. Vocabularies are ontologies,
described (loosely) using RDFS or OWL. These vocabularies are intended
to potentially be used by reasoners. This has resulted in some conventions
for defining OSLC vocabularies such as careful use of rdfs:domain and rdfs:range
because of potential unintended inferences when reusing properties on other
classes. These OSLC conventions are intended to keep the world as open
and flexible as possible as well as to minimize the complexity of the domain
vocabularies.

Shapes on the other hand
are intended to describe constraints for using a vocabulary in a specific
context for a specific purpose. This often requires closing the world down
for that purpose, constraining cardinality, being more specific about oslc:range
for property values, specifying oslc:valueType and allowedValues, etc.
Different shapes can be applied to the same vocabulary for different purposes.
Therefore a set of  RDF resources may or may not satisfy the constraints
of their applicable shapes. OSLC specifies what clients and servers MUST
do if the applicable shapes are satisfied, but does not constrain what
they MAY do if the applicable shapes are not satisfied. This is up to the
implementing tools.</jra>

The properties shown in the
table are controlled by ReSpec. This is a subset of the oslc:Property properties.
The published shape Turtle files have all of the defined property values.
Domains could require changes to ReSpec to display other property values
if needed. </jra>
 
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering
and Management, Mechatronics Division
Brinellvägen 83, SE-100 44
Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile:
+46(0)70 773 93 45
jad@kth.se,
www.kth.se
 
From: Jim Amsden [mailto:jamsden@us.ibm.com]
Sent: 04 February 2016 20:50
To: Jad El-Khoury
Cc: oslc-core@lists.oasis-open.org
Subject: Re: [oslc-core] Review of OSLC Core Vocabulary 3
 
Jad,
Responses in your notes in the attached. Lots of good catches and I've
applied all the updates.


Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:        Jad El-Khoury
<jad@kth.se>
To:        "oslc-core@lists.oasis-open.org"
<oslc-core@lists.oasis-open.org>
Date:        02/03/2016
06:06 PM
Subject:        [oslc-core]
Review of OSLC Core Vocabulary 3
Sent by:        <oslc-core@lists.oasis-open.org>

---

Hi,
 
Attached are my review comments on the “OSLC Core Vocabulary”. A bit
late, but hope it’s not too late!
 
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@kth.se,
www.kth.se
 [attachment "OSLC Core Vocabulary
3.pdf" deleted by Jim Amsden/Raleigh/IBM] 
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php