Updated Wiki to cover proposal

[Charles McCathie Nevile]

Hi,

I updated the Wiki page for the proposal, to separate out the things that
we hope to adopt in schema.org this week.

Note that I did a really rushed job (hopefully I'll have time to improve
on it when I am back from the dentist later), and that I haven't yet done
the work of annotating more clearly what we expect to happen with the rest
of the proposal.

But I figured it was important to communicate at least this much instead
of getting the whole message right before saying anything.

cheers

Chaals

--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
cha...@yandex-team.ru Find more at http://yandex.com

[Charles McCathie Nevile]

Oh. The page in question is
http://www.w3.org/wiki/WebSchemas/Accessibility and it covers the
accessibility proposal for schema.org. I'll annotate it a little further
in the next few hours.

And the values expected are meant to be enumerated - i.e. the valid values
are the list of values as maintained in the wiki. Is there a better
Datatype for that than "Text"?

cheers

Chaals

[Peter F. Patel-Schneider]

schema.org has enumerated types, which might be better to use than text with a list of expected strings.

peter

[Charles Myers]

I have updated Charles McN's edits to the page http://www.w3.org/wiki/WebSchemas/Accessibility to complete the proposal.

The changes are minor organizational and grammatical, changing the prefix of the terms from "access" to "accessibility," improving ambiguities in descriptions and making the properties deferred from the specification more clear.

________________________________________
From: a11y-metad...@googlegroups.com <a11y-metad...@googlegroups.com> on behalf of Charles McCathie Nevile <cha...@yandex-team.ru>
Sent: Sunday, November 17, 2013 6:44 PM
To: <public...@w3.org>; a11y-metad...@googlegroups.com
Subject: [a11y-metadata-project] Updated Wiki to cover proposal

Hi,

cheers

Chaals

--
You received this message because you are subscribed to the Google Groups "Accessibility Metadata Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to a11y-metadata-pr...@googlegroups.com.
To post to this group, send email to a11y-metad...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Charles McCathie Nevile]

On Tue, 19 Nov 2013 02:44:39 +0800, Peter F. Patel-Schneider
<pfpsch...@gmail.com> wrote:

> schema.org has enumerated types, which might be better to use than text
> with a list of expected strings.

Yes, that was what I was thinking... We should make that change.

cheers and thanks

Chaals

[Dan Brickley]

On 18 November 2013 13:36, Charles McCathie Nevile

<cha...@yandex-team.ru> wrote:
> On Tue, 19 Nov 2013 02:44:39 +0800, Peter F. Patel-Schneider
> <pfpsch...@gmail.com> wrote:
>
>> schema.org has enumerated types, which might be better to use than text
>> with a list of expected strings.
>
>
> Yes, that was what I was thinking... We should make that change.

I'm not so convinced yet. There are quite a lot of values, and given
schema.org's flat namespace we would have to consider each term as
_the_ schema.org use of that word.

e.g. MathML; sound; captions; latex; timing etc. would become
http://schema.org/sound ...

My inclination (especially having seen the variety of views earlier in
these discussions) is that allowing Text and also allowing values
represented by URL might be the right combination. Schema.org's
enumerations work best for short, rigid, fixed lists that won't evolve
or get extended...

Dan

[Martin Quiazon]

I'm with Dan on this. In practice there are lots of existing values and
the potential for many future values; it's not feasible to have a fixed
enumeration that encompasses them all.

[Martin Hepp]

+1

--------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail: he...@ebusiness-unibw.org
phone: +49-(0)89-6004-4217
fax: +49-(0)89-6004-4620
www: http://www.unibw.de/ebusiness/ (group)
http://www.heppnetz.de/ (personal)
skype: mfhepp
twitter: mfhepp

Check out GoodRelations for E-Commerce on the Web of Linked Data!
=================================================================
* Project Main Page: http://purl.org/goodrelations/

[Matt Garrish]

Agree. The properties weren't conceived as a closed enumeration, and
defining in the schema.org domain doesn't seem appropriate.

Wasn't the idea of a registry of values floated earlier in the process?

Matt

-----Original Message-----
From: Martin Quiazon
Sent: Monday, November 18, 2013 3:50 PM
To: Dan Brickley ; Charles McCathie Nevile
Cc: Peter F. Patel-Schneider ; <public...@w3.org> ;
a11y-metad...@googlegroups.com
Subject: Re: [a11y-metadata-project] Re: Accessibility for schema.org Re:
Updated Wiki to cover proposal

[Liddy Nevile]

perhaps bear in mind that the ISO standard, for example, will want to
allow for extensions, in the refinement way to maintain structure, so
I agree that lists of literal values could be tricky ...

Liddy

[Liddy Nevile]

Charles,

as others will want to use these terms, I think it'd be good to have
the following description of each term, if possible. The list is
derived from the lists we used in defining DC terms and it is what we
will use in education for the ISO educational metadata terms - it
seems to make everything very clear and to simply give rise to a
useful structure for the terms. It also helps with RDF understanding
of the terms which can be helpful to people wanting extensions who are
not really sure of the rules they need to observe.
Identifier

Property Name

Definition

Linguistic indicator

Domain

Range

Content values

Refines

Example(s)

Note(s)


You ask about the property value 'text' - I think it is better to have
literal and non-literal - and to make sure all 'names' etc are defined
as non-linguistic. Others will know more about this than me - but
that's what I believe is best....

Liddy

[Liddy Nevile]

I note that everything now has a prefix accessibility eg
accessibilityFeature. Does this solve the problem with accessHazard ie
is accessibilityHazard going to be OK??

Liddy

On 18/11/2013, at 7:26 PM, Charles McCathie Nevile wrote:

[Liddy Nevile]

There is a registry proposed in a project run by Gregg Vanderheiden et
al but also, at ISO we are setting up a registry - the proposition has
been for that to be the same as Gregg is talking about but it has not
happened...
I hope what we have for ISO is the same as the schema.org stuff in the
end so would like to have a single registry, for sure..

Liddy

...

[Andy Heath]

On 19/11/2013 00:10, Liddy Nevile wrote:
> There is a registry proposed in a project run by Gregg Vanderheiden et
> al but also, at ISO we are setting up a registry - the proposition has
> been for that to be the same as Gregg is talking about but it has not
> happened...

had not happened *yet* - still in process as I understand it.

> I hope what we have for ISO is the same as the schema.org stuff in the

That needs a little clarification Liddy - I think you are talking about
part 3 of the revision of 24751 that is underway, the first two parts
being the framework and the registry. I think if you just call it ISO
it may confuse - there are many ISO standards of relevance and the one
you are referring to here has several parts as I've said.

andy

andy
andy...@axelrod.plus.com
--
__________________
Andy Heath
http://axelafa.com

[Dan Brickley]

On 19 November 2013 00:10, Liddy Nevile <li...@sunriseresearch.org> wrote:
> There is a registry proposed in a project run by Gregg Vanderheiden et al
> but also, at ISO we are setting up a registry - the proposition has been for
> that to be the same as Gregg is talking about but it has not happened...
> I hope what we have for ISO is the same as the schema.org stuff in the end
> so would like to have a single registry, for sure..

Although sometimes it's a pity to create confusion by specifying two
ways of doing something, in this case I suggest we allow either a)
URLs (e.g.. into a registry, which could use RDFa+SKOS to handle
multllingual labels, simple hierarchy) b) simple inline Text.
Schema.org already has the convention "sometimes when we expect a
'Thing' we half-expect to find a Thing, and we'll do our best with
that...", so this isn't entirely unprecedented. Or as
http://schema.org/docs/datamodel.html puts in (see under Conformance),
""" We also expect that often, where we expect a property value of
type Person, Place, Organization or some other subClassOf Thing, we
will get a text string. In the spirit of "some data is better than
none", we will accept this markup and do the best we can. """".

BTW the parallel discussion here about handling SKOS data in
schema.org shouldn't affect things much. Most likely it means at some
point we might say that these properties have an expected type of -
say - "Topic" instead of 'URL", which would be our way of saying that
they're not just links, but links into an organized system of
identifiable concepts as typically written using SKOS.

Dan

[Charles McCathie Nevile]

On Tue, 19 Nov 2013 01:10:36 +0100, Liddy Nevile
<li...@sunriseresearch.org> wrote:

> There is a registry proposed in a project run by Gregg Vanderheiden et
> al but also, at ISO we are setting up a registry - the proposition has
> been for that to be the same as Gregg is talking about but it has not
> happened...
> I hope what we have for ISO is the same as the schema.org stuff in the
> end so would like to have a single registry, for sure..

Yes, one possibility is that we will have several registries of values.
Which would be a pretty big failure given that we really do want the terms
to be somewhat regularised.

And not making it an enumeration to avoid haveing to make all the types
"the" schema.org version of that seems reasonable to me. In which case
using URLs would be great if people are using the RDFa prefix mechanism,
but would be a right pain in microdata. So I am inclined to suggest that
we maintain the list of expected values on the wiki, and if the various
registry projects turn into something useful we would of course aim to
align quickly.

cheers

Chaals

>>> --You received this message because you are subscribed to the Google

>>> Groups
>>> "Accessibility Metadata Project" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an
>>> email to a11y-metadata-pr...@googlegroups.com.
>>> To post to this group, send email to
>>> a11y-metad...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>

>> --You received this message because you are subscribed to the Google

>> Groups "Accessibility Metadata Project" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to a11y-metadata-pr...@googlegroups.com.
>> To post to this group, send email to
>> a11y-metad...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.

>> --You received this message because you are subscribed to the Google

>> Groups "Accessibility Metadata Project" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to a11y-metadata-pr...@googlegroups.com.
>> To post to this group, send email to
>> a11y-metad...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>


--

[Dan Brickley]

On 19 November 2013 00:07, Liddy Nevile <li...@sunriseresearch.org> wrote:
> I note that everything now has a prefix accessibility eg
> accessibilityFeature. Does this solve the problem with accessHazard ie is accessibilityHazard going to be OK??

There was a problem having a property called 'accessControl'. In a
purely accessibility-oriented setting that might be intuitive. However
schema.org is a general purpose flat namespace, and so the phrase
"access control" is likely to make people think more of passwords,
openid, etc.

Dan

[Madeleine Rothberg]

I think "accessibilityHazard" is fine.

-Madeleine

>--

[Peter F. Patel-Schneider]

You mean like "emergency" is likely to make you think of "A specific branch of
medical science that [...] deals with the evaluation and initial treatment of
medical conditions caused by trauma or sudden illness."?

I think that the non-general purpose name genie is firmly out of the
schema.org bottle.

peter

[Liddy Nevile]

yes, it was name accessControl that I meant...sorry for the confusion

[Charles McCathie Nevile]

On Tue, 19 Nov 2013 23:07:05 +0100, Liddy Nevile
<li...@sunriseresearch.org> wrote:

> yes, it was name accessControl that I meant...sorry for the confusion

Ah. And yes, changing the prefix seems to be a reasonable solution.

cheers

>>>> --Charles McCathie Nevile - Consultant (web standards) CTO Office,

>>>> Yandex
>>>> cha...@yandex-team.ru Find more at http://yandex.com
>>>>
>>>

>>> --You received this message because you are subscribed to the Google

>>> Groups
>>> "Accessibility Metadata Project" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an
>>> email to a11y-metadata-pr...@googlegroups.com.
>>> To post to this group, send email to
>>> a11y-metad...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

[Charles McCathie Nevile]

On Tue, 19 Nov 2013 22:22:53 +0100, Peter F. Patel-Schneider
<pfpsch...@gmail.com> wrote:

> You mean like "emergency" is likely to make you think of "A specific
> branch of medical science that [...] deals with the evaluation and
> initial treatment of medical conditions caused by trauma or sudden
> illness."?
>
> I think that the non-general purpose name genie is firmly out of the
> schema.org bottle.

RIght. But changing the "prefix" in this case (unlike medicalEmergency
which would probably still produce the wrong association) is probably a
reasonable solution to the problem.

cheers

Chaals

> peter
>
> On 11/19/2013 06:48 AM, Dan Brickley wrote:
>> On 19 November 2013 00:07, Liddy Nevile <li...@sunriseresearch.org>
>> wrote:
>>> I note that everything now has a prefix accessibility eg
>>> accessibilityFeature. Does this solve the problem with accessHazard ie
>>> is accessibilityHazard going to be OK??
>> There was a problem having a property called 'accessControl'. In a
>> purely accessibility-oriented setting that might be intuitive. However
>> schema.org is a general purpose flat namespace, and so the phrase
>> "access control" is likely to make people think more of passwords,
>> openid, etc.
>>
>> Dan
>>
>