[Oslc-Automation] 2.0 spec question, and links fixed
Michael F Fiedler
fiedler at us.ibm.com
Wed Nov 6 09:59:49 EST 2013
>From a mail to the list last week:
>
> Question: is the definition of ParameterInstance wrt data types
> ill-defined?
>
> ParameterInstance resource definition table contains this in the
> description of rdf:value:
> "The value of the parameter. rdf:datatype SHOULD be used to indicate the
> type of the parameter instance value."
>
> Yet rdf:datatype is only defined in the context of RDF*/XML*, where it
> gives the data type of a typed literal - and that in turn would affect
> comparison results in other RDF specs like SPARQL, so this is not an
> empty/nop question/series of them.
>
The intent here was consistency with the RDF Concepts definition of
Datatypes [1] which describes it as an abstraction compatible with the
definition of datatypes in XML Schema Part 2. I agree that the RDF Syntax
definition of rdf:datatype [2] does constrain it to RDF/XML.
Possible alternate wording: "If the value is a literal, the datatype for
the literal should be indicated using the syntax appropriate for the
serialization, if one exists.". Other suggestions?
> ParameterInstance's resource definition table row for rdf:value leaves
the
> value unconstrained; in particular, the value (object of the rdf:value
> triple) need not be a literal at all. If it is not a literal, e.g. it is
> a resource reference, it is incoherent to talk about the type of said
> (not-) literal.
The intent here was consistency with the RDF Schema definition of rdf:value
[3], but as I re-read it I think the Automation spec is incorrect. RDF
Schema defines both the domain and range of rdf:value as rdfs:Resource.
>
> Clearly we should not be using RDF/XML-specific syntax to put
requirements
> on the RDF. My best guess at the intent from what is written would be:
> - If the value type is a RDF literal, then it Should be a RDF typed
> literal. [that buys you rdf:datatype when the media type is
> application/rdf+xml]
> - If the value is a resource, ??? I'm guessing no added constraints ???.
Your best guess at the intent is correct. If it is a literal, help the
consumer understand how to interpret it. If it is a resource, the consumer
will likely have to inspect the resource to understand it (or perhaps
inspect its resource shape). Suggestions on how we can make this less
ambiguous in V2?
[1] -
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Datatypes
[2] -
http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-datatyped-literals
[3] - http://www.w3.org/TR/rdf-schema/#ch_value
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131106/a5f5e970/attachment-0003.html>
More information about the Oslc-Automation
mailing list