[oslc-core] Some Topics for Discussion Today
Arthur Ryman
ryman at ca.ibm.com
Mon May 31 11:06:57 EDT 2010
Ian,
Thx for the attachment. I read it. The title talks about "Type Systems".
As you point out, in RDF, the "type" is just another property and
resources may have many types. If we want some resource to be used in
another context, we can add another rdf:type property, in addition to
whatever other properties the resource acquires in the new context, RDFS
and OWL let you infer the type based on the properties, but we don't need
to rely on that.
In the case of Shape resources, we are really talking about resource
descriptions, not specific resource instances, e.g. so we know what
properties to query on or to use for creation. Shape resources are a
simple and very explicit way to represent that info, however, they do
duplicate some capabilities of OWL. We don't want to force spec readers or
implementations to understand OWL. However, we could regard Shape
resources as a kind of syntactic sugar for OWL.
So I agree with your observation that OWL can describe Shapes. I think we
can use OWL in the background as a guide on our Shape resources, i.e.
let's at least be consistent with OWL where we overlap.
BTW, I noticed a problem in your paper. In the following example you use
owl:equivalentClass, but I think you should use rdfs:subClassOf:
<owl:Class rdf:about="#PotentialPlanItem">
<owl:equivalentClass>
<owl:Restriction>
<owl:onProperty rdf:resource="#enddate"/>
<owl:someValuesFrom rdf:resource="#Date"/>
</owl:Restriction>
</owl:equivalentClass>
<owl:equivalentClass>
<owl:Restriction>
<owl:onProperty rdf:resource="#estimatedeffort"/>
<owl:someValuesFrom rdf:resource="#float"/>
</owl:Restriction>
</owl:equivalentClass>
<rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing
"/>
</owl:Class>
The intension is that PotentialPlanItem has both an enddate and an
estimatedeffort, i.e. it lies of the intersection of the restriction
classes defined by either property.
Regards,
___________________________________________________________________________
Arthur Ryman, PhD, DE
Chief Architect, Project and Portfolio Management
IBM Software, Rational
Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
Twitter | Facebook | YouTube
From:
Ian Green1 <ian.green at uk.ibm.com>
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
05/27/2010 10:51 AM
Subject:
Re: [oslc-core] Some Topics for Discussion Today
Hi Arthur
some of my OWL thinking can be found in the attached document. perhaps it
would provoke a discussion? (The "OWL" parts in the attached document -
Simon nor Ed commented on that so they may not agree with what I wrote.)
You suggestion that we could offer a mapping to OWL is not something I'd
considered, but would offer a way to put shape on a firmer basis without
pulling in the complexity of the underlying RDF model. It would also
finesse the intractability of OWL DL. I'm not sure that it would lead to
a common understanding of the meaning of the OSLC resource shape
vocabulary.
best wishes,
-ian
ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
Chief Software Architect, Requirements Definition and Management
IBM Rational
oslc-core-bounces at open-services.net wrote on 26/05/2010 13:59:42:
> [image removed]
>
> [oslc-core] Some Topics for Discussion Today
>
> Arthur Ryman
>
> to:
>
> oslc-core
>
> 26/05/2010 14:00
>
> Sent by:
>
> oslc-core-bounces at open-services.net
>
> 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.
>
> 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]
>
> "So as not to affect the conformance of existing implementations of
> "simple Dublin Core" in RDF, domains and ranges have not been specified
> for the fifteen properties of the dc: namespace
> (http://purl.org/dc/elements/1.1/). Rather, fifteen new properties with
> "names" identical to those of DCMES Version 1.1 have been created in the
> dcterms: namespace (http://purl.org/dc/terms/). "
>
> 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?
>
> [1] http://dublincore.org/documents/dcmi-terms/
>
> Regards,
>
___________________________________________________________________________
>
> Arthur Ryman, PhD, DE
>
>
> Chief Architect, Project and Portfolio Management
>
> IBM Software, Rational
>
> Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
> Twitter | Facebook | YouTube
>
>
>
>
>
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JFS Type Model.odt
Type: application/octet-stream
Size: 18808 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100531/714ab816/attachment.odt>
More information about the Oslc-Core
mailing list