[Accessforall] Minutes of AccessForAll Meeting on 2012-01-31
schwer at us.ibm.com
Mon Feb 13 16:50:09 UTC 2012
Not all metadata may be directly referenced. They may be part of a JSON
data structure describing the widget where the corresponding resources
themselves would be reference via a URL. We may not get service offerings
to expose all metadata through a registry. This is a strategy discussion.
From: Liddy Nevile <liddy at sunriseresearch.org>
To: "Accessforall at fluidproject. org"
<Accessforall at fluidproject.org>,
Date: 02/10/2012 03:56 PM
Subject: Re: [Accessforall] Minutes of AccessForAll Meeting on
Sent by: accessforall-bounces at fluidproject.org
Are we not over-complicating things?
As I understand it, all resources/services that will be delivered to
the user will have their own identifiers and these can be of many
types - eg - it might be a physical object in a library or it might be
a digital object or it might be a physical event. The main thing is
that it is on the web because there is a digital reference to it on
the web. (That, of course, is Tim Berners-Lee's definition of the web.)
All these resources/services, or even better, all components of them,
will be described so that what suits a user's needs and preferences
can be delivered to them. These descriptions are metadata 'values' and
they will be in all sorts of places, including sometimes openly
available to everyone and sometimes within closed systems.
The terms (properties) that are used to describe the resources/
services will be in a registry so they can be found by machines
processing the metadata values and also by people wanting to craft new
sets of properties (so they can use ones already crafted if possible).
So the only identifiers we are concerned with right now are those that
relate to the definition of the properties and these should be in
namespaces in the registry. I think it is good to have a core set that
caters for a lot of people (with common things like font-size) and
then lots of detailed refinements of that core.
I think we are thus talking about URIs taking us to the registry
(hopefully) or elsewhere if people have properties borrowed from
elsewhere or crafted and stored elsewhere. So we want URIs. We want
the registry to be available to anyone who wants to add new properties.
Is that any need for anything more?
Mitsuharu Nagamori who has been working on this stuff for ages says:
"I recommend Open Metadata Registry which provides services to
developers and consumers of controlled vocabularies.
I recommend taking his advice.
On 11/02/2012, at 4:20 AM, Gregg Vanderheiden wrote:
> On Feb 10, 2012, at 6:25 AM, Andy Heath wrote:
>> I believe a URL gives a means to access a resource
>> - subtly different from where the resource came from (not that that
>> has impact for the matter here).
> actually the URL should lead directly to the location of the
> registry that the info came from.
>> I don't think the URL/URI distinction is important at this point
>> but it might become so after we considered how people and tools
>> interact with "the" registry. It is easily revisited later.
> A URI SHOULD also lead you directly there. But it would require
> that there are universal servers (e.g. universal name server for a
> URN) and they don't exist.
> so for theoretical discussions URI is fine. But now that I think
> about it -- I think we should stick with URL so it will actually work.
>> I called it ""the" registry" because it occurred to me while I was
>> thinking about the URL/URI question is that there are ways to do
>> this where there are federated registries (which is one way to
>> filter culturally for example) - but in my mind we are talking
>> about a single registry here - as specified in 1.
> I think we will have one COMMON TERMS registry for GPII - but there
> will be many since each company or creator can create new TERMs for
> their product(s) and they will not be in th COMMON TERMS registry
> We are setting up a mechanism for companies to store them next to
> (but not in) the COMMON TERMs registry but that is for convenience -
> not required. Companies can put their terms anywhere they like --
> and the URL would point to them. At least that is the current plan
> -- subject to modification with better ideas. We are implementing
> one now however since we need it in the next 60 days to be
> Accessforall mailing list
> Accessforall at fluidproject.org
Accessforall mailing list
Accessforall at fluidproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 105 bytes
Desc: not available
More information about the Accessforall