Fwd: MiniSKOS proposal: add Topic, an equivalentClass to skos:Concept, and relate schema properties to it.

[Phil Barker]

Hello folks, here's a proposed change to schema.org that affects an important bit of LRMI.

In summary the idea is to allow certain properties to have a Topic as their value,  where the type "Topic" covers "categories, controlled lists of values, subject classification codes (e.g. UDC, Dewey), thesauri and other controlled codes".  The properties of a Topic would be the same as Thing (see http://sdo-wip1.appspot.com/Topic)

One of the properties which could have Topic values would be the AlignmentObject targetUrl.

On the whole I think this is a welcome move as it is a step towards a more thorough description of the educational frameworks to which we may express an alignment.

Question: do we support this as-is? An alternative would be to suggest adding the property "target" to AlignmentObject, where target would have expected type Topic.

If Topic is added as an expected type to targetURL then sometimes we may see complex values comprising the url, name, description etc. of the target in the educational framework given as targetURL.

If we add a target property, then the targetURL (if present) should always be a simple URL, but sometimes the information that currently is marked up as targetDescription, targetName and targetURL would be marked as the name, description and URL of a Target item.

Phil

-------- Original Message --------

Subject:	MiniSKOS proposal: add Topic, an equivalentClass to skos:Concept, and relate schema properties to it.
Resent-Date:	Tue, 19 Nov 2013 20:22:40 +0000
Resent-From:	<public...@w3.org>
Date:	Tue, 19 Nov 2013 20:22:06 +0000
From:	Dan Brickley <dan...@google.com>
To:	W3C Web Schemas Task Force <public...@w3.org>, Stéphane Corlosquet <scorl...@gmail.com>

"MiniSKOS proposal for schema.org"

This is a greatly minimized proposal for Schema.org <-> SKOS
integration. I didn't make a wiki entry for it yet; maybe it's best to
add it to http://www.w3.org/wiki/WebSchemas/SKOS than make a separate
writeup?

Essentially, we add one type 'Topic', we say it is an equivalent class
to W3C skos:Concept, and then we focus on identifying properties in
schema.org where it can be an expected type.

RDFS: https://dvcs.w3.org/hg/webschema/file/default/schema.org/ext/miniskos.html
Test build: http://sdo-wip1.appspot.com/Topic

We add a range of 'Topic' to these properties: about,
occupationalCategory, targetUrl, applicationCategory,
applicationSubCategory, category, mentions, serviceType.

This would be our way of saying that (sometimes) the values of these
properties would take links into existing controlled vocabularies,
typically but not necessarily documented using W3C SKOS in (hopefully)
RDFa. By doing so, we make it easier for schema.org data to use
hierarchies of controlled codes, alternate and multilingual labels,
and links between such vocabularies.

All other information about a Topic would be expressed in
non-schema.org vocabulary (broader etc.), most likely SKOS.

Dan

[Dan Brickley]

On 20 November 2013 12:56, Phil Barker <phil....@hw.ac.uk> wrote:

Hello folks, here's a proposed change to schema.org that affects an important bit of LRMI.

In summary the idea is to allow certain properties to have a Topic as their value,  where the type "Topic" covers "categories, controlled lists of values, subject classification codes (e.g. UDC, Dewey), thesauri and other controlled codes".  The properties of a Topic would be the same as Thing (see http://sdo-wip1.appspot.com/Topic)

One of the properties which could have Topic values would be the AlignmentObject targetUrl.

On the whole I think this is a welcome move as it is a step towards a more thorough description of the educational frameworks to which we may express an alignment.

Question: do we support this as-is? An alternative would be to suggest adding the property "target" to AlignmentObject, where target would have expected type Topic.

If Topic is added as an expected type to targetURL then sometimes we may see complex values comprising the url, name, description etc. of the target in the educational framework given as targetURL.

If we add a target property, then the targetURL (if present) should always be a simple URL, but sometimes the information that currently is marked up as targetDescription, targetName and targetURL would be marked as the name, description and URL of a Target item.

Thanks for raising this here, Phil!

Given the name of the property, I would be surprised if many people used a 'targetURL' property to point to an inline Topic that was described locally rather than in a remote page. But you never know what people will try. I see the concern about http://schema.org/AlignmentObject having properties that are similar to properties of Topic. If we can establish a trend towards having machine-readable authority data, e.g. as Library of Congress publish for LCSH, http://id.loc.gov/authorities/sh85108275#concept ... then perhaps it will become unnecessary for each educational resource description to also list all those details. In the meantime having the name/description etc inline is not unreasonable.

LRMI and educational code markup is certainly one of the motivations for this (mini)SKOS proposal, so let's make sure we have a design that works here.

cheers,

Dan

[Phil Barker]

On 20/11/13 14:30, Dan Brickley wrote:

On 20 November 2013 12:56, Phil Barker <phil....@hw.ac.uk> wrote:

Hello folks, here's a proposed change to schema.org that affects an important bit of LRMI.

In summary the idea is to allow certain properties to have a Topic as their value,  where the type "Topic" covers "categories, controlled lists of values, subject classification codes (e.g. UDC, Dewey), thesauri and other controlled codes".  The properties of a Topic would be the same as Thing (see http://sdo-wip1.appspot.com/Topic)

One of the properties which could have Topic values would be the AlignmentObject targetUrl.

On the whole I think this is a welcome move as it is a step towards a more thorough description of the educational frameworks to which we may express an alignment.

Question: do we support this as-is? An alternative would be to suggest adding the property "target" to AlignmentObject, where target would have expected type Topic.

If Topic is added as an expected type to targetURL then sometimes we may see complex values comprising the url, name, description etc. of the target in the educational framework given as targetURL.

If we add a target property, then the targetURL (if present) should always be a simple URL, but sometimes the information that currently is marked up as targetDescription, targetName and targetURL would be marked as the name, description and URL of a Target item.

Thanks for raising this here, Phil!

hello Dan :)

Given the name of the property, I would be surprised if many people used a 'targetURL' property to point to an inline Topic that was described locally rather than in a remote page. But you never know what people will try.

I think it could happen by accident, especially if user interfaces hide the schema.org names in favour of more user friendly labels or locally recognised terms. Or if someone thought they would be clever and take advantage of some of the other properties that Topic gives you. After all this doesn't too odd at first read:

<div  itemscope itemtype="http://schema.org/CreativeWork">
    <h1 itemprop="name">My learning resource</h1>
    <div itemprop="educationalAlignment" itemscope itemtype="http://schema.org/AlignmentObject">
        <span itemprop="alignmentType">teaches</span>
        <a itemprop="targetUrl" itemtype="http://schema.org/topic" itemscope href="http://example.org/id">
            <span itemprop="name">Some topic</span>
            <span itemprop="alternateName">Same topic</span>
        </a>
    </div>
</div>

I see the concern about http://schema.org/AlignmentObject having properties that are similar to properties of Topic.

Personally I'm not too concerned about having two equivalent ways of expressing the same information, but I think life would be simpler if they were distinct.

If we can establish a trend towards having machine-readable authority data, e.g. as Library of Congress publish for LCSH, http://id.loc.gov/authorities/sh85108275#concept ... then perhaps it will become unnecessary for each educational resource description to also list all those details. In the meantime having the name/description etc inline is not unreasonable.

Agreed.

LRMI and educational code markup is certainly one of the motivations for this (mini)SKOS proposal, so let's make sure we have a design that works here.

Thanks, Phil


[in case anyone is wondering, here's the structured data testing tool output for the example above:

Item
type:    http://schema.org/creativework
property:   
    name: My learning resource
    educationalalignment:    Item 1

Item 1
type:    http://schema.org/alignmentobject
property:   
    alignmenttype:    teaches
    targeturl:  Item 2

Item 2
type:    http://schema.org/topic
property:   
    name:    Some topic
    alternatename:    Same topic

see
http://www.google.com/webmasters/tools/richsnippets?q=uploaded:8004eb9e15ddf7635dcafce5cf5c23b1

-- 
work: http://people.pjjk.net/phil
twitter: https://twitter.com/#!/philbarker

Ubuntu: not so much an operating system as a learning opportunity.
http://xkcd.com/456/

[Joshua Marks]

Phil and Dan,

 

The description below of alternate educationalAlignment targets sounds useful including a topic “Topic” reference. I think I need to understand it better before giving a +1, but am positive by some fraction of 1.

 

Joshua Marks

Chief Technical Advistor (CTA)

Curriki: The Global Education and Learning Community

jma...@curriki.org

www.curriki.org

 

I welcome you to become a member of the Curriki community, to follow us on Twitter and to say hello on our blog, Facebook and LinkedIn communities.

--
You received this message because you are subscribed to the Google Groups "Learning Resource Metadata Initiative" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lrmi+uns...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Phil Barker]

Thanks Joshua.
If anyone would like further explanation I can try, just let me know what to focus on.

Phil

-- 
<http://www.icbl.hw.ac.uk/~philb/>

---

Sunday Times Scottish University of the Year 2011-2013
Top in the UK for student experience
Fourth university in the UK and top in Scotland (National Student Survey 2012)

We invite research leaders and ambitious early career researchers to join us in leading and driving research in key inter-disciplinary themes. Please see www.hw.ac.uk/researchleaders for further information and how to apply.

Heriot-Watt University is a Scottish charity registered under charity number SC000278.

[Dan Brickley]

On 20 November 2013 23:29, Joshua Marks <jma...@curriki.org> wrote:
> Phil and Dan,
>
> The description below of alternate educationalAlignment targets sounds
> useful including a topic “Topic” reference. I think I need to understand it
> better before giving a +1, but am positive by some fraction of 1.

Thanks! Just to keep folks here up to date, ... the proposal since
yesterday is leaning towards using the name "ConceptCode" rather than
"Topic", to address cases like job/skill/role taxonomies where the
word "topic" feels a bit of a stretch. I could live with either. See
'miniskos' threads in
http://lists.w3.org/Archives/Public/public-vocabs/2013Nov/ for
discussion.

Dan