[Accessforall] Minutes of AccessForAll Meeting on 2012-01-31

Andy Heath andyheath at axelrod.plus.com
Fri Feb 10 12:25:30 UTC 2012


Embedded comments
> Good question
>
> Anyone have a reason to limit this to URLs rather than allowing URIs?
>
> Only thing I know of is that the URL makes it possible to know where the
> Source or location of the Registry is that the preference come from. And
> it guarantees it is unique. Not sure if URI's would all have the same
> attributes. (URLs are one type of URI for those not familiar).

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

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.

andy
>
> RE #8 - that should pretty much be an outcome of the other statements if
> they are true.
>
> /Gregg/
> --------------------------------------------------------
> Gregg Vanderheiden Ph.D.
>
>
>
> On Feb 9, 2012, at 6:05 PM, Andy Heath wrote:
>
>>
>>> So does anyone have a problem with any of these statements? Or
>>> suggestions to tune them (these are basic statements so should be simple
>>> -- including only IMPORTANT caveats)
>>
>> One question. Should we say URI rather than URL so as to allow other
>> kinds of identifier ? If we were talking about content then use cases
>> for use of URI's as identifiers are legion. I can't think of a case
>> where a registered preference would need to be a URI but not a URL -
>> I'm just asking if anyone can. The others I'm fine with, though there
>> is work to determine exactly what 8. means in practice.
>>
>> andy
>>>
>>>
>>> 1. The registry will contain a flat structure,
>>> 2. URLs are fine namespaces.
>>> 3. What is supposed to be read by machines should be easy for machines
>>> to read
>>> 4. What is supposed to be read by humans should be easy for humans to
>>> read
>>> 5. The website and its presentation of the /*Needs & Preferences
>>> Registry */should be user friendly.
>>> 6. The preference profiles and preferences themselves as read by the
>>> machines should be easy for machines to read and process.
>>> 7. The specific mechanism for representing the namespace is an
>>> implementation-specific detail. In XML, they'll be represented using
>>> colons and the xmlns attribute, and in other formats they may be
>>> represented differently.
>>> 8. It should be possible for implementations or presentations of the
>>> /Needs & Preferences Registry Entries / to be presented flat,
>>> hierarchically or in other formats to aid in viewing but no
>>> particular view should be required by the structure.
>>> 9. Nothing in the ISO 24751 or AccessForAll standard should prevent
>>> implementations or anything else from representing using
>>> hierarchical (or any other) data structures, I
>>> 10. Tags on the registry items are not part of the registry items and
>>> would not be part of preferences profiles.They're a tool (for use on
>>> our web site or elsewhere) to enable users to sort, search, and view
>>> the registry's content.
>>> 11. Tags are NOT PART OF the registry items but associated with them.
>>> RtF will maintain one set based on the GPII workgroup input for use
>>> on the RtF/GPII site.
>>> 12. But there COULD be other sets of TAGS generated by other people that
>>> would organize and present the registry entries differently on other
>>> web sites. The tags could also be constructed so that they would
>>> create a Hierarchical presentation of the registry items. But again
>>> - that is a presentation of the items. The items themselves stand
>>> alone as items in a flat registry.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Feb 9, 2012, at 4:12 PM, Clark, Colin wrote:
>>>
>>>> Hi All,
>>>>
>>>> And from my end, I had a minor epiphany while on the subway this
>>>> morning that helps me join the violent agreement. Here's a summary:
>>>>
>>>> * Gottfried's proposal fully makes sense to me now, and I agree with
>>>> it. The registry will contain a flat structure, and URLs are fine
>>>> namespaces.
>>>> * Unlike the UIC example we've been bouncing around, our website and
>>>> registry should be more user friendly. As Liddy says, URL are for
>>>> machines, words are for people. We'll just need to design a better
>>>> interface for the registry.
>>>> * The specific mechanism for representing the namespace is an
>>>> implementation-specific detail. In XML, they'll be represented using
>>>> colons and the xmlns attribute, and in other formats they may be
>>>> represented differently.
>>>> * As long as nothing in the standard prevents implementations from
>>>> representing ISO 24751 using hierarchical (or any other) data
>>>> structures, I'm fine with whatever structure we like within the
>>>> specification and registry. Flat is a-okay.
>>>> Gregg and I chatted further on the phone about his tags idea, and he
>>>> clarified that the tags were only designed for the registry system
>>>> itself, not part of the preferences profile. In other words, they're a
>>>> tool on our website to enable users to sort, search, and view the
>>>> registry's content. Sounds good to me.
>>>
>>>
>>>
>>> _______________________________________________
>>> Accessforall mailing list
>>> Accessforall at fluidproject.org <mailto:Accessforall at fluidproject.org>
>>> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall
>>
>>
>>
>> Cheers
>>
>> andy
>> --
>> __________________
>> Andy Heath
>> http://axelafa.com
>>
>> _______________________________________________
>> Accessforall mailing list
>> Accessforall at fluidproject.org
>> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall
>



Cheers

andy
-- 
__________________
Andy Heath
http://axelafa.com



More information about the Accessforall mailing list