RE: Should we adopt SKOS?

IDs of terms can effectively be used  to instantiate classes or properties in rdfa or microdata statements but not much will happen if they can't be dereferenced (dereferenciated ?:--).

In a schema.org paradigm, probably things undertsood by schema.org will be preferred e.g. to ingest dereferentiated triples as linked data to be added to the triple store (whatever implementation it is) . Therefore, what jean has been proposing yesterday makes sense as an appropriate way to declare SKOS in a schema-org friendly way. 

Of course this is only one option. I can see a case for a HTML documentation that contains some rdfa/microdata plus an RDF file for those who wnat to use it.

As you say, it is for those who host vocabularies to provide these in the right (e.g. SKOS for schema.org ) format and the intention is not to have schema-org duplicate vocabularies in yet another format (also because you will never avoid others to create their own dictionary). Having a way to simply share SKOS vocabularies in a schema.org paradigm would make it benefit from a load of resources.

I am also worried by some of the things that have been said as it reflects uncxertainties on some fundamentals.

JP

________________________________________
From: Karen Coyle [kcoyle@kcoyle.net]
Sent: 11 January 2013 18:16
To: public-vocabs@w3.org
Subject: Re: Should we adopt SKOS?

I agree with Mike on this, although I have a slightly different set of
objections. As I understand schema.org, it is markup for visible text,
with some accommodation for additional description that is not visible
to the web page reader (e.g. standardized date formats, identifiers for
named things that have a standard ID). The value space is generally
assumed to be the visible text. For controlled value lists, it is
recommended that external lists be used. [1] Presumably, if the values
have been defined in RDF or SKOS, their identifiers can be included in
the non-visible markup.

If you think of schema.org from a product point of view, most
manufacturers have a number of fixed sets of values: the blender comes
in two colors; the car comes in 6 colors and 3 interior types; the
notebook in two sizes; etc. These change from model to model, and are
specific to that manufacturer. It seems clear to me that these lists
should be managed by the manufacturer external to schema.org.

Any defined value that has broader usability can be on the list of
helpful external lists and its identifier included in the microdata
markup. (Geonames, for example; BISAC subjects as another.) I have not
seen in this discussion an example of a value for which a
schema.org-specific identifier would provide capabilities that cannot be
provided by an external list.

With Mike and others I am concerned that the discussion is moving away
from semantic mark-up of visible text to a full metadata standard
including control of the value space. I think this adds a complication
that threatens the usability of schema.org for its original purpose.

kc


[1] http://blog.schema.org/2012/05/schemaorg-markup-for-external-lists.html

On 1/10/13 8:50 PM, Mike Bergman wrote:
> Hi All,
>
> I have a recommendation on the SKOS issue, if you will bear with me, but
> the length of this inherited thread and its esoterica, I think, affirm
> two observations:
>
> 1) since the Good Relations adoption, there is a desire (precedent) to
> want to find additional vocabularies that can be sanctioned by
> schema.org's market position
>
> 2) schema.org risks becoming the new forum for all sorts of semantic
> folly and discussion.
>
> I think both of these are a mistake.
>
> As for 1), I can appreciate that Martin has worked the system well
> enough to get his vocabulary accepted. It is a good vocabulary, and
> Martin is a diligent advocate. But, frankly, I don't think this is a
> model we want to see perpetuated. There are multiple realms that
> conceivably deal with important dimensions of the "schema" scope; do we
> seriously think it is the role of this forum to find those encompassing
> descriptions?
>
> Vocabulary acceptance is ultimately, I think, a market position, and not
> any role or responsibility of schema.org.
>
> The *sponsors* of schema.org, however, do have what amounts to much
> market clout. If they like something, they will adopt it; if not, they
> won't. The choices they make as players in making schema.org stuff
> prominent or not will (in part) determine their own market performance.
> I accept this, and whatever this forum does, it has no ultimate bearing
> on these sponsors' market decisions. This forum is not the W3C (and even
> the W3C making such determinations has little bearing on this market).
>
> I also firmly believe that vocabulary extensions from concepts to
> products to whatever should be accommodated for within a schema.org
> framework. My issue is solely whether any single extension warrants
> sanction. Extension mechanisms, yes; specific vocabularies, no.
>
> As for 2), I think that is just a natural outcome of looking to
> schema.org as some kind of "answer" to what used to be known as the
> "chicken-and-egg dilemma" for the semantic Web. The best thing about
> schema.org is that it is a pragmatic forum to discuss prominent types of
> things and their attributes.
>
> My advice is to try to keep schema.org as a relatively pure location for
> important value:pair discussions. We'll get to the big stuff -- and
> perhaps even schema.org will be in part one vehicle for doing so --
> by-and-by, but this is a forum for *market importance* not theory.
>
> As for the SKOS stuff, we (Structured Dynamics) use it much. But the
> premise of the adoption into schema.org fits into that same
> dysfunctionality I noted above: trying to make schema.org an umbrella
> for sanctioned subsidiary vocabularies. I believe this to be a Bad Idea.
>
> My simple suggestion is to move "about" to become a property of Thing
> and not CreativeWorks (which, after reflection, is a placement that is
> silly). Then, with an extension mechanism that recognizes an external
> namespace (say, gr: or umbel: or dc:) enable that (or perhaps, many
> other schema: properties) to extend the umbrella.
>
> As for SKOS, I think it is generally orthogonal to a schema.org
> specification. Like any vocabulary on the Web, map to the concepts that
> make sense for you. If "about" with namespace recognition were added to
> schema.org, there would be no further questions about what to do with
> SKOS or any other Web vocabulary.
>
>      schema.org != semantic web
>
> Thanks, Mike
>

--
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

------------------------------------------------------------------------------

**************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please notify the system manager. This footnote also confirms that this email message has been swept by the mailgateway
**************************************************

Received on Friday, 11 January 2013 17:37:17 UTC