[Oslc-Automation] 2.0 spec question, and links fixed

[Michael F Fiedler]

>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>