oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [oslc-core] Core Vocabulary and Resource Shapes ready for TC review
- From: "Jim Amsden" <jamsden@us.ibm.com>
- To: oslc-core@lists.oasis-open.org
- Date: Wed, 6 Jan 2016 09:00:09 -0500
Martin,
Thanks for the great review. Comments
embedded below...
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
From:
"Martin P Pain"
<martinpain@uk.ibm.com>
To:
Jim Amsden/Raleigh/IBM@IBMUS
Cc:
arthur.ryman@gmail.com,
oslc-core@lists.oasis-open.org
Date:
01/05/2016 07:02 AM
Subject:
Re: [oslc-core]
Core Vocabulary and Resource Shapes ready for TC review
Sent by:
<oslc-core@lists.oasis-open.org>
> 2. OSLC Resource Shape 3.0: https://tools.oasis-open.org/version-control/svn/oslc-core/trunk/specs/resource-shape.html
1. In the first paragraph in the introduction,
the LDP reference is not a link (and has a double opening square bracket:
"[[LDP]").
<jra>Fixed</jra>
2. Do we want the recommendations for extensions
in there? We could always link back to the W3C submission instead of duplicating
them. I don't think they are particularly useful to people writing implementations
- I see them as more useful to groups such as us or the Data Shapes WG.
<jra>Agreed, but before
we remove them, lets be sure there are none we want to include in OSLC
Core 3.0.</jra>
3. Section 2, terminology, "applicable":
It states how to determine if a shape is "applicable", but doesn't
say what the consequence of that is. Also, this (along with the "oslc:describes
Property" section under 8.1) suggests that a Resource Shape cannot
be used with any resource at all if the shape does not have an oslc:describes
property, yet that property is stated as allowing Zero-or-many values.
Section 6.2 allows for a shape with no oslc:describes value to be applicable
to any resources that is "associated" with it.
I suggest that we remove the criteria of
being "applicable" from that definition (as it's currently incorrect,
and is too complicated to summarise briefly) and link to section 6.2 instead,
and then state only the consequence of applicability in the terminology
section. Such as:
"applicability: For all shapes that
"apply to" a resource, that resource should satisfy the constraints
defined by those shapes. See section 6.2 for the definition of what shapes
apply to a resource, and what it means if multiple shapes apply to a single
resource."
<jra>Agreed and updated
to your content.</jra>
4. Section 2, terminology, "association":
This also doesn't state the consequence of association. I'd leave the criteria
for association here, as it's simple enough, but perhaps also insert "The
shapes associated with a resource are the set of shapes to be checked for
applicability." before "Not all the associated shapes are necessarily
applicable."
<jra>Agreed, change inserted.</jra>
5. Section 5, requirements. The second paragraph
(which has been added into what was taken from the W3C submission) appears
out of place. The first paragraph is introducing the list that follows
the second paragraph. The second paragraph sound like it belongs in the
abstract or introduction.
<jra>I moved the paragraph
to the introduction.</jra>
6. Section 6.1, overview, paragraph about "The box
labelled 'Property'":
This says "The arrow labeled "property"
represents the containment relation between a shape and its defined properties."
I believe in the context of either UML or LDP, the word
"containment" implies single ownership. Do we know if that is
what is intended here? I would expect oslc:Property resources to be able
to be re-used by multiple shapes, therefore not "contained" within
the shape in the sense of UML or LDP containment.
Although the property is required to be inline, both the
v2 document and the W3C submission have with "value-type" set
to "Resource", which should allow it to have a URI, which allows
it to be re-used, especially between two shapes in the same document (which
would not require duplication of the single inlined resource).
<jra>I think this is
using "Containment" in its more general term, not implying either
aggregation or composition. I'll change that to aggregation relationship
to make the intent clearer.</jra>
7. Next paragraph, starting "Each oslc:Property":
Where it says "and the constraints on its use within
any resource of the given shape". I think this would be more accurate
to say "and the constraints on its use within any resource that the
given shape applies to", as this explicitly refers to the "applicability"
term, and therefore indirectly to section 6.1. The wording "of
the given shape" could be ambiguous.
<jra>Agree, fixed.</jra>
That's as far as I've got for now. Unfortunately
that means I haven't got to the main part of the document...
I intend to finish reviewing this document
and also check what feedback I've already given for the delegated dialogs
document, but I'm not sure I'll get anything more done before the meeting
this week.
Martin
----- Original message -----
From: "Jim Amsden" <jamsden@us.ibm.com>
Sent by: <oslc-core@lists.oasis-open.org>
To: oslc-core@lists.oasis-open.org
Cc: arthur.ryman@gmail.com
Subject: [oslc-core] Core Vocabulary and Resource Shapes ready for TC review
Date: Tue, Dec 22, 2015 5:14 PM
OSLC Core 3.0 draft documents are ready for TC review:
1. Core Vocabulary: https://tools.oasis-open.org/version-control/svn/oslc-core/trunk/specs/core-vocab.html
This update includes the ResourceShapes for common properties from OSLC
Core 2.0 and other OSLC Core 3.0 common properties. It also provides the
complete OSLC Core 3.0 vocabulary.
The approach used to capture common Dublin Core, RDF, RDFS, FOAF and OSLC
properties was to use a resource shape CommonProperties which has no oslc:describes
property. This is supported by OSLC Resource Shapes 2.0, and is intended
to describe properties that could be applied to any resource. This is a
proposed resolution to issue OSLCCORE-43 that:
1. doesn't define any root OSLC resource
2. doesn't require any of the properties - they are all optional
3. uses a uniform way of displaying properties in the specs using ReSpec
4. provides the common properties in a machine readable Turtle file like
any other shape properties.
Unfortunately ReSpec does not yet support ResourceShapes that do not include
oslc:describes, see issue OSLCCORE-55. As a work around, CommonProperties
oslc:describes is set to oslc:Any in order to get the shapes tables to
render properly. That will be removed when the ReSpec defect is fixed.
2. OSLC Resource Shape 3.0: https://tools.oasis-open.org/version-control/svn/oslc-core/trunk/specs/resource-shape.html
We decided that in order to maintain compatibility with OSLC v2.0, and
recognizing significant use by existing products, we must continue to support
OSLC Resource Shapes, with other LDP constraint languages such as SHACL
as additional options. I had considered how best to include ResouceShapes
into the OSLC Core 3.0 specifications including:
1. simply referencing the current OSLC
Core 2.0 Common Properties
2. migrating OSLC
Core 2.0 Common Propertiesinto
the OSLC Core 3.0 vocabulary: core-vocab.html
3. utilizing the W3C Resource
Shape 2.0 draft specification
with the updated content and descriptions
I compared the W3C Resouce Shape 2.0 draft with OSLC Core 2.0 Common Properties
and found them to be completely compatible. In order to leverage the great
work Arthur did in cleaning up Resource Shapes 2.0, I decided to migrate
the W3C draft to OASIS and include it as part of the OSLC Core 3.0 multi-part
specifications. I also extracted the resource shapes and properties from
the two documents into new ResouceShapes-shape.ttl and resource-shape-vocab.ttl
files. These files are used in the resource-shape.html draft specification
to generate the properties tables using ReSpec.
Core Vocabulary as well as Core Overview now refer to the new OSLC Resource
Shape 3.0 draft.
This completes the TC draft specifications for OSLC Core 3.0 and OSLC Change
Management 3.0 which refers to OSLC Core 3.0 and represents a use of Core
for further validation. Once the TC reviews are done and the final edits
are completed, these working drafts can be submitted for public review.
As always, send editorial comments to this mailing list, and raise any
significant issues in the issues list: https://issues.oasis-open.org/browse/oslccore.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
--------------------------------------------------------------------- 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]