Hey Mikael
feel free to engage at least some accessibility people in this
debate, please! I remember now that we did touch on it ages ago and
I, for one, acceded that meta-metadata did not belong in the abstract
model ...
but then, when it came up again, I said it was of interest and could
be like EARL. Does EARL do the wrong thing, then?
As for the provenance and DC Accessibility, I am not pushing for that
now but saying it'd be 'nice' - discussing it further on the
accessibility list might take the discussion out of reach of many
accessibility people who are not architecture people - and may not be
necessary.
Does the abstract model say, or need to say, that one cannot have
attributes of attributes etc in the statement, that go beyond the
abstract model? If so, we could never add together a DC statement in
RDF with another that relates to the resource without having to strip
it first, surely? I mean, should DC metadata be specified to be a set
of 'at least' things that can be combined with other things in the
sense that they appear together in a single file or in a compilation
of files?
Liddy
On 23/02/2007, at 7:51 AM, Mikael Nilsson wrote:
>
> On fre, 2007-02-09 at 11:59 +0100, Makx Dekkers wrote:
>> Pete,
>>
>> Maybe you can explain this issue a bit further? I was following the
>> discussion on DC-Accessibility as well but did not see a deeper issue
>> other than a potential need to be able to say that a resource
>> does NOT
>> have a certain attribute.
>>
>> How are the deeper issues (the truth of statements and describing
>> changes) related to that?
>>
>> Is this implying that the Dublin Core Abstract Model would break as a
>> result of someone lying (deliberately or by accident) in the
>> metadata? I
>> hope not!
>
> No, it would not break....
>
> But, just as with RDF, as soon as one defines a metadata model that
> allows for easy merging of information from many sources, the source
> itself becomes interesting.
>
> Now, modeling the source is *not* explicitly part of either RDF or the
> DCAM, and it's a difficult task.
>
> It's been done in RDF, but mostly in an incorrect way,
> unfortunately...
>
> For comparison, see the NewsML framework, which adds a lot of
> information to each "statement", like "confidence" etc.
>
> Handling metametadata like the above is very much out of scope at the
> moment, but is likely to become more important. As soon as we exit the
> domain of "objective" knowledge (which is pretty small) we find this
> problem.
>
> I'd really love to engage the accessibility and education people in
> this
> debate, as it's something that needs to be handled consistently
> across a
> number of fields....
>
> /Mikael
>
>
>>
>> Makx.
>>
>>
>>> -----Original Message-----
>>> From: DCMI Architecture Forum
>>> [mailto:[log in to unmask]] On Behalf Of Pete Johnston
>>> Sent: Friday, February 09, 2007 11:16 AM
>>> To: [log in to unmask]
>>> Subject: [DCAM Public Comment] Monotonicity?
>>>
>>> There's a long and rather complicated thread on the
>>> dc-accessibility list at the moment which (essentially, I
>>> think) circles around notions of how to "say" that a resource
>>> does not have some attribute, and touches on broader notions
>>> of describing changes in some attributes of a resource.
>>>
>>> Charles McCathieNevile makes the point here
>>>
>>> http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0702&L=dc-acc
>>> essibility
>>> &P=2075
>>>
>>> that while this sort of thing can be represented using RDF
>>> and DCAM, it does require some very careful modelling. I
>>> think generally this area - that once a statement is made, it
>>> is expected to be true - is something that we've tended to
>>> skirt over in DC generally, and I wonder whether it merits a
>>> paragraph somewhere in the DCAM (though I'm not volunteering
>>> to write it!)
>>>
>>> Pete
>>> ---
>>> Pete Johnston
>>> Technical Researcher, Eduserv Foundation
>>> Web: http://www.eduserv.org.uk/foundation/people/petejohnston/
>>> Weblog: http://efoundations.typepad.com/efoundations/
>>> Email: [log in to unmask]
>>> Tel: +44 (0)1225 474323
>>>
>>>
>>
> --
> <[log in to unmask]>
>
> Plus ça change, plus c'est la même chose
|