[oslc-core] Some Topics for Discussion Today

[Dave]

Thanks for these items Arthur. Responses are below...


On Wed, May 26, 2010 at 8:59 AM, Arthur Ryman <ryman at ca.ibm.com> wrote:
> 1. I've been digging deeper into OWL and there does appear to be a way to
> express the kind of information we are putting in our Shape resources,
> e.g. cardinality. The OWL way is somewhat more complex - it involves class
> restrictions. Our Shape approach is easier for clients to handle. I think
> we should at least describe the semantics of Shape in terms of OWL so we
> are compatible. We may be able to regard Shape as a simplified form for
> the equivalent OWL.

We discussed this in the WG meeting this week and I think it is a good
idea even if we do not end up adopting or referencing OWL. By
comparing and contrasting to OWL we may learn of flaws or limitations
of our shapes concept.


> 2. Our use of Dublin Core namespace prefixes seems a little inconsistent
> with common practice. We are using the newer terms namespace,
> http://purl.org/dc/terms/ instead of the legacy elements namespace
> http://purl.org/dc/elements/1.1/. However, the usual prefix for the terms
> namespace seems to be dcterms: while the elements namespace uses dc:.  I
> suggest we adopt this convention and use dcterms: as the predefined and
> recommended prefix. See [1]

I wrote this up on the issues page. Here's what I wrote for the resolution:

Response: this is not a new situation, the old v1 specs used the new
namespace and the old prefix too. We seem to have two options now:
1) Continue to use the new Dublin Core namespace and to use the old
"dc" prefix. Pros: no change to implementations, won't break badly
behaved clients who have hardcoded the namespace prefix. Cons: does
not follow Dublin Core conventions
2) Switch to using the new "dcterms" prefix. Pros: follows Dublin Core
conventions. Cons: could break badly behaved clients.

After writing that I think changing is a bad idea. Here's why.

In theory, recommending "dcterms" as the prefix won't break
implementations because XML parsing tools can handle any prefix for a
namespace -- so this change should be no problem. But, in practice, I
worry that we may have some badly behaved implementations, that we had
no way to declaring prefixes in query URIs and that we had no way to
declare prefixes in our JSON representations -- so query URIs and JSON
representations could be broken by this change.

And, according to that same theory, we should be able to stick with
the old "dc" prefix because XML parsing tools can use any prefix for a
namespace. We won't break existing implementations if we stick with as
the "suggested prefix" for Dublin Core elements. So, why change
anything?

Maybe I'm not understanding the benefits of making this change. Are
there more "pros" to changing than what I have listed?


> 3. I think we should establish or identify a best practice for services
> that provide access to resources through both http and https. In this
> case, the same resource is being made available at two different URLs. The
> resource should have one preferred URI which appears in the resource
> representations, is used for links, etc. If we don't establish a preferred
> URI then queries, etc. could get complex. Anyone have experience with this
> situation?

We discussed this one in the WG meeting as well and concluded that we
should not establish best practices for this in the Core spec or
guidance.

Thanks,
Dave