[oslc-core] Expressing oslc:valueType and/or oslc:range within RDFS
Arthur Ryman
ryman at ca.ibm.com
Wed May 30 14:16:08 EDT 2012
John,
One problem is that oslc:valueType is defined for use in resource shapes.
It is associated with how a predicate is used within resource graph. If
you use it directly on the predicate, then that would imply a constraint
for any resource graph. We'd have to spell that out.
Regards,
___________________________________________________________________________
Arthur Ryman
DE, Chief Architect, Reporting &
Portfolio Strategy and Management
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)
From:
John Arwe <johnarwe at us.ibm.com>
To:
oslc-core at open-services.net
Date:
05/24/2012 08:36 AM
Subject:
Re: [oslc-core] Expressing oslc:valueType and/or oslc:range within
RDFS
Sent by:
oslc-core-bounces at open-services.net
I had a sense on the call that you guys were talking past one another, and
now it's deja vu all over again.
The key is probably your question (from the call) "do you [Steve] mean RDF
annotations?".
I wasn't sure what those were (well-defined &something vs term of art) at
the time; after some brief research, I think the answer is "yes".
One example: when defining the RDFS document for an OSLC vocabulary, we
could just stick an oslc:valueType predicate inside the property
definition (assuming the syntax allows it, but I expect so this is RDF
after all and it's "just another triple").
Fair to say we cannot do so for vocabulary we do not control, but they
would not appear in our vocabulary documents anyway. The resource
definition table would be the only obvious place we could constrain
something like dcterms:created to be an xs:dateTime vs Dublin Core's
rdfs:Literal range.
I think we did agree on the call that using Range in our own RDFS was
inappropriate, precisely for the reasons you articulate. oslc:valueType
is a predicate we control, and a generic RDFS processor therefore will
infer no additional triples unless we license it to do so. Or am I
missing something?
Best Regards, John
Voice US 845-435-9470 BluePages
Tivoli OSLC Lead - Show me the Scenario
From: Arthur Ryman <ryman at ca.ibm.com>
To: Steve K Speicher/Raleigh/IBM at IBMUS
Cc: oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date: 05/23/2012 10:38 PM
Subject: Re: [oslc-core] Expressing oslc:valueType and/or
oslc:range within RDFS
Sent by: oslc-core-bounces at open-services.net
Steve,
I commented on this on a recent telecon. In summary:
1. RDFS and OWL are inference languages. They define rules for deriving
new triples from given triples. This is not what we mean when we indicate
the value type of a predicate.
2. Our tables document how predicates are used within a resource (or more
narrow context such as resource creation). This applies to predicates we
define or reuse, e.g. Dublin Core, FOAF. These are constraints on what
constitutes a valid RDF representation of a resource. These constraints
cannot be part of the vocabulary since we do not control Dublin Core or
FOAF. That is why we introduced ResourceShapes.
One technical nit - RDF terms are not QNames, they are URIs. A QName is a
pair (namespace URI, local name). Syntactically a QName looks like a CURIE
(Compact URI), but they mean something different. RDF/XML conflates these.
Regards,
___________________________________________________________________________
Arthur Ryman
DE, Chief Architect, Reporting &
Portfolio Strategy and Management
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)
From:
Steve K Speicher <sspeiche at us.ibm.com>
To:
oslc-core at open-services.net
Date:
05/16/2012 09:54 AM
Subject:
[oslc-core] Expressing oslc:valueType and/or oslc:range within RDFS
Sent by:
oslc-core-bounces at open-services.net
In thinking about best to define our vocabularies in a reusable way across
other domains within OSLC and beyond, I think it would be good to be able
to define each vocabulary term as:
Predicate QName -- Value Type QName -- Meaningful description string --
Some indication of its maturity [stable | learning | proposed]
It would also be desirable to use a normative way to express these
vocabularies with RDF Schema/OWL or OSLC Resource Shapes. Then derive our
human-readable versions from them (like we do today) and provide
scenario-specific constraints such as read-only and occurs.
Take for example what we have in Core Common Properties [1] and Linked
Data Basic Profile [2], it follows this pattern mostly. With [1] we have
some extra details and with [2] we possibly lump value types within the
Range heading, implying rdfs:range perhaps wrongly.
It appears that RDFS doesn't provide a great way to indicate "Value Type
QName" and need to determine if OWL plays a role here. The usage of
rdfs:range is limited to rdfs:Classes, so things like xsd:String are not a
rdfs:Class.
So to better "explain" the common or expected value type, I'm suggesting
we just reuse oslc:valueType within our RDFSs. The valid choices for
oslc:valueType will be same as defined in current Core V2 spec +
rdf:Resource.
Additionally, we would create a predicate to indicate the term's maturity
or use a recommended one.
Any feedback on this approach? Suggestions on a better mechanism?
I looked around [3] for some best practices on this and appears to be a
bit spotty on the usage, other than just simply a local defined rdfs:range
object or using rdfs:Literal.
[1] - http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] - http://www.w3.org/Submission/ldbp/#bpr-prop
[3] - http://dublincore.org/schemas/rdfs/
Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
More information about the Oslc-Core
mailing list