RE: ODRL JSON-LD examples (was Re: ODRL Version 2.1 Final Draft Specifications )

> My question then becomes: given a search engine that is reading JSON-LD and schema.org terms, do you project that the searching engine (Google, Yandex, Yahoo, Bing) is able to process this code above directly, in some automatic fashion, via the 
> @context for <odrl/2/jsonschema#>, and thereby identify the ODRL values given? 
> (Even if it's never encountered <odrl/2/jsonschema#> before?)
>
> Or, does the search engine need to have pre-processed <odrl/2/jsonschema#>, and have made a (human-mediated) policy decision to include the <odrl/2/jsonschema#> terms, before the ODRL values can be identified and used from the above code?

These are questions about schema.org. At present, schema.org (and hence the search engines which implement it) do not support ODRL type statements. Given that, I believe these FAQs are relevant, since they talk about how schema.org plans to evolve:

https://schema.org/docs/faq.html#5

Q: What's coming next? How will schema.org evolve?
Schema.org is a work in progress which will keep evolving over the next many years. We expect the evolution to come from two major sources.
As we identify new kinds of structured data that we can use to provide better search results, we will extend schema.org to cover these.
We strongly encourage schema developers to develop and evangelize their schemas. As these gain traction, we will incorporate them into schema.org.

https://schema.org/docs/faq.html#12

Q: My website contains content that is of a type that is unsupported. Are you going to add that type? How do I mark it up in the meantime?
If you publish content of an unsupported type, you have three options:
Do nothing (don't mark up the content in any way). However, before you decide to do this, check to see if any of the types supported by schema.org - such as reviews, comments, images, or breadcrumbs - are relevant.
Use a less-specific markup type. For example, schema.org has no "Professor" type. However, if you have a directory of professors in your university department, you could use the "person" type to mark up the information for every professor in the directory.
If you are feeling ambitious, use the schema.org extension system to define a new type.

As for the specific questions to do with JSON-LD, I believe these FAQs are relevant:

https://schema.org/docs/faq.html#11

Q: I have already added markup in some other format (i.e. microformats, RDFa, data-vocabulary.org, etc). Do I need to change anything on my site?
If you are already publishing structured data markup and it is already being used by Google, Microsoft, Yandex or Yahoo!, the markup format will generally continue to be supported. Changing to the new markup format could be helpful over time because you will be switching to a standard that is accepted across all three companies, but you don't have to do it.

https://schema.org/docs/faq.html#14

Q: Why microdata? Why not RDFa or microformats?
Focusing on microdata seemed like a pragmatic decision at the time. For some time now we have been supporting multiple syntaxes, specifically including RDFa and JSON-LD. There are certain things that are much harder in Microdata, like mixing vocabularies, or inverting the direction of a property relationship. We are also adding code examples in all of these formats.

So, having something (like ODRL) marked up on webpages means it is a candidate for inclusion in schema.org. I suspect that the more webpages that contain a type of markup (like ODRL) the more likely that schema.org would consider it. I also know, from personal experience, that directly working with (lobbying) schema.org makes it much more likely that they will consider it. The exact format that is used to markup metadata on a webpage (microdata, microformats, RDFa, JSON-LD, data-vocabulary.org and so on) are less import from the schema.org point of view.

Regards,

Stuart




-----Original Message-----
From: Steven Rowat [mailto:steven_rowat@sunshine.net] 
Sent: Wednesday, January 21, 2015 12:11 PM
To: public-odrl@w3.org
Subject: Re: ODRL JSON-LD examples (was Re: ODRL Version 2.1 Final Draft Specifications )

On 1/21/15 5:00 AM, Renato Iannella wrote:
> This could be the blind leading the blind...but from what I can see in 
> using multiple contexts in JSON-LD [1] and taking the AudioObject JSON 
> example [2]....could we have this:

Thank you Renato. I've attempted to follow it and looked at the links you provided, and I think I roughly understand the layout. And it is the kind of solution I was groping towards.

To the degree that I understand it, and in terms of the ODRL terms used in the second part of your example:

[
   {
      "@context": "http://schema.org",
      "@type": "AudioObject",
...   },
   {
      "@context": "http://www.w3.org/ns/odrl/2/jsonschema#",
      "policytype": "http://www.w3.org/ns/odrl/2/Set",
      "policyid": "http://example.com/policy:0099",
      "permissions": [{
         "target": 
"http://media.freesound.org/data/0/previews/719__elmomo__12oclock_girona_preview.mp3",
         "action": "http://www.w3.org/ns/odrl/2/reproduce"
       }]
    }
  ]

My question then becomes: given a search engine that is reading JSON-LD and schema.org terms, do you project that the searching engine (Google, Yandex, Yahoo, Bing) is able to process this code above directly, in some automatic fashion, via the @context for <odrl/2/jsonschema#>, and thereby identify the ODRL values given? 
(Even if it's never encountered <odrl/2/jsonschema#> before?)

Or, does the search engine need to have pre-processed <odrl/2/jsonschema#>, and have made a (human-mediated) policy decision to include the <odrl/2/jsonschema#> terms, before the ODRL values can be identified and used from the above code?

Steven Rowat






The information contained in this communication is intended for the use
of the designated recipients named above. If the reader of this 
communication is not the intended recipient, you are hereby notified
that you have received this communication in error, and that any review,
dissemination, distribution or copying of this communication is strictly
prohibited. If you have received this communication in error, please 
notify The Associated Press immediately by telephone at +1-212-621-1898 
and delete this email. Thank you.
[IP_US_DISC]

msk dccc60c6d2c3a6438f0cf467d9a4938

Received on Wednesday, 21 January 2015 17:28:46 UTC