On 8/10/12 8:06 AM, Thomas Baker wrote:
>> I also want to note that the inclusion of SES here with a URI could
>> be read to imply something more than rdf:Datatype. If SES=datatype,
>> then rdf:Datatype becomes simply one of the possible value patterns
>> for the Object, and further description of the SES isn't needed, it
>> is simply another possible value: typed data as defined in
>> rdf:Datatype.
>
> I'm not quite sure I entirely follow, because RDF datatypes are identified by
> URIs, but I agree that typed literals would simply fit into one (or more)
> possible value patterns. DCAM itself, then, would have a sentence or two
> explaining what SES/datatypes are and pointing off to RDF specs, on the one
> hand, and to exemplars on the other.
Tom, I can't reconstruct what I was thinking when I wrote that first
clause, so I'll take that back. However, what I have understood in some
of the group discussions is that this line in the DCAM definitions:
"syntax encoding scheme (http://www.w3.org/2000/01/rdf-schema#Datatype)"
is interpreted by some people as meaning that the SES = rdf:Datatype. In
other words, that there is no difference. If there is no difference
between them, then defining the SES is redundant with rdf:Datatype, and
"rdf:Datatype" should be used in its stead -- otherwise people will
logically assume that they are different in some way. SES would need to
be defined if it differs from rdf:Datatype in any way. In that case,
giving it a different name makes sense, and it would be a good idea to
emphasize what the differences are in the DCAM document.
>
>> In a sense, I see the current DCAM as both an
>> explanation of RDF concepts as well as building on them, in which
>> sense the entire "value surrogate" area needs revision or removal.
>
> The notion of "value surrogate" has been, without a doubt, the single most
> confusing (and annoying) aspect of DCAM for readers. A handful of well-chosen
> example patterns would be easier for users to grasp.
I agree. And I also think that we need a clear picture of the
relationship between DCAM and RDF. As I recall, you (or someone) stated
that when DCAM was being developed, RDF wasn't yet fully defined. So now
there may be aspects of DCAM that are no longer needed (because they
have been defined in the RDF specifications) or that may need to change
because they are not compatible with the RDF specifications. I'm trying
to determine if we see DCAM being built directly on RDF, as an
extension, or if the group feels that there needs to be some redundancy
between DCAM and RDF for the purposes of clarification (of RDF).
I say this in particular because of the use of "literal/non-literal" in
DCAM which uses different terminology from RDF's "plain literal/typed
literal." [1] I don't know if there are other areas where DCAM and RDF
are incompatible, either in terminology or conceptually, but I assume
that this group should be looking at this.
kc
[1] http://www.w3.org/TR/rdf-concepts/#section-Literals
>
> Tom
>
> [1] http://dublincore.org/documents/2007/06/04/abstract-model/description-set-model.jpg
> [2] http://dublincore.org/documents/dc-rdf/#app-a
>
>
>
>
>
>> kc
>>
>>
>>>
>>> Instead of trying to define such higher-level patterns in DCAM itself, these
>>> patterns could be documented in the form of exemplars. The challenge, then,
>>> would be to define a DCAM+DSP sort of language expressive enough to express
>>> those exemplars in a consistent and comparable way. Ideally, those exemplars
>>> would be machine-actionable, but they would ideally also be readable -- either
>>> directly, because they were written in a Pythonesque indentation style without
>>> brackets, or indirectly by automatic transformation into, say, a Web page.
>>>
>>> Tom
>>>
>>> [1] http://lists.w3.org/Archives/Public/public-lld/2010Nov/0114.html
>>>
>>
>> --
>> Karen Coyle
>> [log in to unmask] http://kcoyle.net
>> ph: 1-510-540-7596
>> m: 1-510-435-8234
>> skype: kcoylenet
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
|