Does json-ld have a equivalent to microdata's itemref?

[jarnovandriel]

Hi everybody,

I'm wondering whether by now json-ld has an equivalent to microdata's itemref?

Reason I ask is because I'm working on service listings which describe 1 service per listing yet each item in the list has its own subset of properties for that service (including offers, opening hours, provider, etc). So what I'd like to do is define 1 data island for a service and refer to that data, like one can do with itemref, for each item in the list, thus preventing me from having to specify the entire service for each item in the list .

[unifirst...@gmail.com]

Can you use @ids?

1) define id:

{"@type": "Service",

    "id": "#yourService",

   "property": "value",

    etc....

    }

 

2) make multiple references to id:

"property": {"@id": "#yourService"},

[jarnovandriel]

Alas using an @id as such won't work as each instance of the service in the listing would have to have the same @id. And given that each listing item has some additional properties and values that are unique for that entity, using the same @id would cause all those instances to coalesce into a single service, where they have to be separate entities.

[Jarno van Driel]

To say it differently, what I'm hoping to achieve (like we can do with itemref) is to create a data island of a Service which has all the properties filled out which are the same for all all services in the list, so I can pull that data into all those services in the list and only fill out those properties of each service that are unique to the individual item.

[Thad Guidry]

Sounds like a Type, or Class to me... they all share the same properties...

and then a few are multi-typed with some specific Types that hold their unique properties.

Thad

https://www.linkedin.com/in/thadguidry/

https://calendly.com/thadguidry/

On Fri, Feb 5, 2021 at 8:29 AM Jarno van Driel <jarnov...@gmail.com> wrote:

To say it differently, what I'm hoping to achieve (like we can do with itemref) is to create a data island of a Service which has all the properties filled out which are the same for all all services in the list, so I can pull that data into all those services in the list and only fill out those properties of each service that are unique to the individual item.

--
You received this message because you are subscribed to the Google Groups "Semantic Search Marketing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to semantic-search-ma...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/semantic-search-marketing/CADK2AU1LVV%3DEC3wz12EXF%2BEWOonx8hp2qmU_-%3DoS%3DtxdXq1zmw%40mail.gmail.com.

[Tony McCreath]

It sounds similar to what ProductGroup is trying to solve, but for a single scenario. The docs there use the term prototype or template which I think fits this better. 

I made up a few @ properties, but maybe something like this would provide support for this need (in some distant future)...

{

    "@type": "Service",

    "@id": "#template1",

    "@abstract": true,

    "property": "value"

},

{

    "@type": "Service",

    "@id": "#service1",

    "@template": {"@id": "#template1"}

    "property2": "value2"

},

{

    "@type": "Service",

    "@id": "#service2",

    "@template": {"@id": "#template1"}

    

    "property2": "value3"

}

@abstract indicates don't consider this an entity on its own.

@template mean add the referenced entities properties to the current entity.

[jarnovandriel]

"Sounds like a Type, or Class to me... they all share the same properties...

and then a few are multi-typed with some specific Types that hold their unique properties."

That's not it either. The class/type I'm using is a schema.org/Service, and the items in the list are of that same type.

What I'd like to do is to create a schema.org/Service that has properties like name, alternatename, sameAs completely filled out and use the data as sort of a blueprint for the services in the list (which are the exactly the same service) so that I only have to fill out the properties which are specific for each service in the list (properties like offers, openingsHours, provider).

Schema.org offers a solution of sorts in it's vocabulary with ProductModel and ProductGroup but alas, these are for products. Now microdata allows me to create a data island of properties with itemref but alas the project I'm working is done in JSON-LD and hence the reason I'm looking for a json-ld solution for microdata's itemref.

And if there's none, that means I'll be forced to fill out the default properties for every single service in the list, which means quite the extra amount of KBs in the markup.

[Gregg Kellogg]

We considered such a feature, which ultimately proved too much for the algorithms.What we have left from that is @included, which any do some of what you want. See https://github.com/w3c/json-ld-syntax/issues/19 for a discussion.

Gregg Kellogg

Sent from my iPad

On Feb 5, 2021, at 6:29 AM, Jarno van Driel <jarnov...@gmail.com> wrote:



To say it differently, what I'm hoping to achieve (like we can do with itemref) is to create a data island of a Service which has all the properties filled out which are the same for all all services in the list, so I can pull that data into all those services in the list and only fill out those properties of each service that are unique to the individual item.

--

[jarnovandriel]

"I made up a few @ properties, but maybe something like this would provide support for this need (in some distant future)..."

Something like that indeed Tony.

"We considered such a feature, which ultimately proved too much for the algorithms.What we have left from that is @included, which any do some of what you want. See https://github.com/w3c/json-ld-syntax/issues/19 for a discussion."

oh wow, I would have never guessed that could be too much for algo's, especially since it can be done in microdata (and I have done so plenty in the past). Makes me sad to hear that it's back to the old duplicate the data until you drop method but so be it (until it changes).

Thanks for the resource Gregg, gonna dive into in a sec.

[Tony McCreath]

Looks interesting. I'll have to allocate another json-ld day to continue trying to get my head around all this.

Thanks Greg.

[jarnovandriel]

"I'll have to allocate another json-ld day to continue trying to get my head around all this."

hehe, let it be clear I don't presume I'll ever fully understand many of the things Gregg (and friends) have said and done - simply way above my level of understanding of all that's involved. I'll happily settle for the the smaller and simpler nuggets Gregg throws at us every now and then and feel enriched beauce of them.

The more advanced topics/resources are more a way for me to keep my feet on the ground and always remember there's tons of learning to do still and never to think you know it all. Similar to Gregg,  Thad also throws a ton of resources and learnings around all the time. 2 gents which until this day still can be cause for me losing a lot sleep while endlessly wandering around in a gazillion little corners on the web (and in archives).

Can't help enjoying the voyage though.

[Tony McCreath]

Some time this year I went down the rabbit hole from understanding how to write structured data for Google, to writing a tool to validate it. It's like knowing how to drive a car, to learning how to build one, and build the parts. A whole world I had no idea about.

[Martin Hepp]

I think there are two issues behind what you try to achieve:

1. A mechanism for reusing parts of a data structure, similar to a macro.
2. A mechanism for defining variants of an entity.

Historically, GoodRelations and schema.org have tried to leave out mechanisms for #1 and preferred the materialization of the final data structures. So if a product is available in three sizes, we would create the full data for three products etc. An exception are patterns for opening hours where we had a model for recurring patterns.

A common motivation for a more compact form of markup and a vocabulary for representing *rules* that define variants and repeating entities is that the data will be less verbose.

While this is true in the raw form, it does not hold if you factor in data compression, which is standard in HTTP by now. It makes no difference whether you represent a rule using your vocabulary or whether you use a program to materialize the output of the rule, and then compress it with ZIP or something else. At least in theory, ideal solutions of both will have the same size (because they contain the same information entropy).

On the contrary, production rules in a vocabulary and macro mechanisms in a syntax create a wealth of theoretical and practical problems.

Just a few:

1. Unclear identity criteria
You may be tempted to represent multiple properties using the same data structure which happen to carry the identical value at the moment but have a different path of evolution.
This may sound purely theoretical, but can lead to practical problems. (See the vast amount of discussion on blank nodes in RDF ;-).

2. Circular references and decidability
You can easily create faulty data structures for which the processing will lead to infinite loops or other problems.

3. More cost for the consuming component
What you save at the markup level may lead to much more complicated processing for the consuming client.
For instance, answering a query will require that the query processor will match both materialized objects (e.g. fully specified products) and rules defining a set of variants.

Now, consider that the Web is a vastly distributed, evolving system, with caching, CDNs etc.

In Web development, we see a trend to static site generators, which are basically following the "materialization" paradigm, rather than DB-powered, dynamic Web sites.

Personally, I found itemref interesting, but too complex and error-prone for many developers, and it was mainly needed because of the false popularity of reusing the same literals for visible content and for data markup in the era of RDFa and Microdata. Fortunately, it is now commonly agreed that reusing visible content for data markup is inferior to separate blocks of JSON-LD. While JSON-LD blocks repeat some of the values from the HTML elements for visible content, we are freed from aligning the data markup with the organization of the HTML DOM. Such worked well only for trivial vocabularies and/or if the data model matches the HTML DOM, which is rare as soon as legacy HTML templates kick in.

So in a nutshell, I think we do not need an mechanism like itemref in JSON-LD. You can always use global identifiers so reference sub-structures (albeit the support by search engines is limited), or put the rules for variants or macros in the server-side components in any programming language you want.

Hope that helps!

Best wishes
Martin Hepp

> --
> You received this message because you are subscribed to the Google Groups "Semantic Search Marketing" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to semantic-search-ma...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/semantic-search-marketing/3813197f-3f4f-42ed-a833-ae2dcd1f685dn%40googlegroups.com.

[Jarno van Driel]

Thanks for sharing your thoughts Martin.

Let it be clear I'm not arguing for adding an itemref like feature to json-ld, I was just curious whether something similar already exists or not. For the first time (which illustrates the exceptionality of the situation) since json-ld came to be I finally ran into a real-life situation where having it would have been a nice feature, though a case can definitely be made that what I was was hoping to do finds it constraints in the schema.org vocabulary and not so much with the syntax I'm using.

As a pure theoretical solution I could use ProductGroup since a Product can be used to describe a Service as well though somehow, to me, that feels like stretching the semantics too far. Plus the variesBy property still is quite limited (for now) in regards to its expected values, meaning I still wouldn't be able to make use of some form of prototype/template and only describe the variants of the service.

Hopefully something we can work on with schema.org in the future.

Op di 9 feb. 2021 om 13:20 schreef Martin Hepp <mfh...@gmail.com>:

[Martin Hepp]

Hi Jarno:

FYI: We are thinking of a generic mechanism for modeling product and services variants in schema.org, but it will take time as it must be suitable for a broad range of industries. ProductGroup and isVariantOf a currently the only options available.

Best wishes
Martin

[Thad Guidry]

Jarno,

It's not stretching the semantics... just mentally replace ProductGroup with ThingGroup. 

Albino rabbits, rare mushrooms we call truffles, etc. are ProductGroup:"Rare"in my fake ecommerce system, and Rare products hasVariant:"Asteroids" included in it.

Any Thing can be categorized as a Product essentially.

Does that help you with the semantics now? :-)

[Jarno van Driel]

"Does that help you with the semantics now? :-)"

No it doesn't, though that definitely has to do with me personally and not so much the vocabulary.  ;-)

<sort-of-rant>

From day one I never understood why Goodrelation's ProductOrService was split in two. I understand the politics and considerations behind it but I just have little sympathy for the practical issues that historic decision created, as in: 

Not all properties under Service are also available under Product and vica versa and to make things worse the big search engines don't support Service at all (at least in regards to their search features). Meaning folks that don't know schema.org that well have to make all kinds of mental jumps to understand they can use Product to describe a Service if they want to get Rich Results and that in that case they should use 'seller' to describe a 'provider' but that if they want to describe the hours a Service is available they have to create an MTE (["Product","Service"]) to be able to use 'hoursAvailable' - an MTE that states something is a Service twice yet somehow different??? For many having to make such jumps this simply is non-logical and thus stay stuck in describing a Service without ever knowing they could have done so much more...

Anyways, "just mentally replace ProductGroup with ThingGroup." technically isn't so much the issue for me personally, and I'm aware that there's follow up work to do for 'variesBy' (meaning a vocabulary solution for my issue is just a matter of time) but as things get more complicated around Product (and its related types) I do feel the fact Product and Service are separate things (yet still similar) over time will become more problematic for publishers, especially for those that are new to schema.org.

</sort-of-rant>

Op di 9 feb. 2021 om 15:10 schreef Thad Guidry <thadg...@gmail.com>: