question on place name, gs1:AI, SGLN extension #35
Comments
|
Hi @VladimirAlexiev , @philarcher @philarcher - please see especially my response to ##5 below - and correct me if you disagree with my suggestion to use the # fragment of a URI as a safer way to construct additional Web URIs derived from GS1 Digital Link URI stems. Re ##1 and ##4, you can currently use schema:name . When we finish the preparations to submit the work request to update the GS1 Web vocabulary with the extensions to the GLN data model, we expect that the corresponding properties gs1:physicalLocationName and gs1:digitalLocationName will be added, complementing the existing gs1:organizationName (which only applies to instances of gs1:Organization). Re ##2, I don't think this is correct use of ^^gs1:AI. Like its counterpart, schema:globalLocationNumber , gs1:globalLocationNumber only expects a plain xsd:string - not an instance of the data type gs1:AI. The only property within the GS1 Web vocabulary having a rdfs:range of gs1:AI is gs1:applicableTo - though currently no subproperties of gs1:linkType appear to make use of this. The data type gs1:AI is used as values of the skos:notation property for annotating various properties (such as gs1:bestBeforeDate etc.) to indicate an equivalence to a specific GS1 Application Identifier. Re ##3, I'd have written it as Re ##5, I'm not sure that I'd encourage that approach. I understand that you want to avoid using a blank node and may want to refer to that node elsewhere / again. Your proposal of Thanks for asking - and for suggesting potential improvements. We're hoping to submit the work request to add the GLN-related extensions in January 2022, so potentially those could be available just in time for the GS1 Global Forum - and we can put the preview draft (in JSON-LD and Turtle) in this repository when we submit the work request, although there might be some (hopefully only minor) tweaks by the GMD SMG. |
What is the appeal of making such specific properties when you can write queries with triple patterns like the following? When I see something so specific as Having a name is having a name no matter what kind of thing you are, right? |
|
Hi @justin2004 Specialised properties can be useful for disambiguation between related properties. I've provided a few examples below. For example, a product may have a familiar name (e.g. 'Disprin') created by its brand owner ( expressed via https://www.gs1.org/voc/productName ) but it might also have a functional name about its purpose (e.g. 'pain relief / anti-inflammatory') ( expressed via https://www.gs1.org/voc/functionalName ) and in some cases may also have a regulated product name ( https://www.gs1.org/voc/regulatedProductName ), which in this example might be something like 'dispersible/soluble aspirin tablets'. All three of these have their uses. For some pharmaceuticals it may be a regulatory requirement to state the regulated product name. There is also value in expressing the functional name, to make the product discoverable by anyone searching for products that match a particular purpose or generic name or category. Organisations may have a registered legal name as well as a trading name. Whereas schema.org has a single weight-specifying property for a product, https://schema.org/weight, the GS1 Web vocabulary provides three or four: https://www.gs1.org/voc/grossWeight So if you are trying to provide the weight details for a jar of pickled onions, as a consumer you might be most interested in the gs1:drainedWeight (the onions), less interested in the gs1:netWeight (the onions and the vinegar) and probably only interested in the gs1:grossWeight (the onions, the vinegar and the glass jar) if you needed that value to calculate the postal charges or were concerned about the weight of your shopping bags if planning to buy multiple jars. The jar of pickled onions is a good example where there can be a significant difference between these values. For example, a drained weight of 220g but a net weight of 440g and a gross weight of 670g. Likewise, for dimensions, the GS1 Web vocabulary provides separate properties for 'in package' depth, height, width, diameter as well as for 'out of package' depth, height, width and diameter. In contrast, schema.org does not make this distinction - so you don't really know whether a schema.org/width includes the width of the packaging material or not. Where the GS1 Web vocabulary provides more specialised properties, we have usually declared these to be rdfs:subPropertyOf the corresponding generic property defined by schema.org - and through this, it's easy to SPARQL CONSTRUCT / INSERT an extra set of triples - although if several of our related specialised properties were specified simultaneously, you might be confused if you find that the inferred schema:weight is multi-valued for that jar of pickled onions. If you prefer not to make use of the specialised properties, that's your choice - but it's probably not a choice made by over a million brand owners / manufacturers globally who have a need for such specialised properties and more specific definitions agreed over the course of many years through a consensus-based standardisation process, GS1's GSMP. |
(written before I saw @justin2004)
That's a different need. (written before I saw @mgh128's example from CompanyHouse) Mark, all examples you give are of needs for semantically different props, not props applied to different classes
That's not the point. The point is that if I need to express the Do you dispute that for pretty much any kind of object, you need a common "name" for display purposes? Schema has a lot of "universal" props, see https://schema.org/Thing
Hmm, the ontological mappings from GS1 to Schema are a whole different topic and not as simple as you intimate.
And that process didn't think that Places want to have
Like I agree with you, but I think @philarcher's page shows that all identifier-valued props have that datatype (range)?
Agree with you. Then I'll use
Ok, will use
The server (GS1 or other resolver) won't see the fragment. Why do that: |
|
Hi @mgh128 , Thanks for the examples. The case for gs1:productName, gs1:functionalName, and gs1:regulatedProductName is a bit different than the case for gs1:organizationName, gs1:physicalLocationName. and gs1:digitalLocationName. The former don't fix their domain as tightly. Also they each do mean something a little more specific than schema:name. I do feel like they make sense as separate properties. But the latter only seem to be proposed to fix their domain tightly and they mean the exact same thing: schema:name. The weight and dimensions properties are interesting because I think they do match how people talk about things but it isn't quite the same jar of pickles that has a gross, net, and drained weight. In each state, some matter has been added/removed through a process. Maybe pickles could exist in various states: Each of those states would still have a But I don't feel strongly enough about this distinction at the moment. :) |
|
I don't dispute that some of our existing properties in the GS1 Web vocabulary may have been too restrictive in their rdfs:domain. We have recently made some updates to the linkType properties for GS1 Digital Link to make those more generally applicable to various kinds of thing - not restricted to products. We're also making a similar update to make gs1:CertificationDetails more generally applicable. I'm sure that there are other terms where we could either broaden the rdfs:domain or question whether we need a related term defined per class. Part of the historical background is that the GS1 Web vocabulary straddles the gap between schema.org and the GDSN data model (which does have a tendency to define such terms per class). We do some things in a less clunky way than in the GDSN data model but there is probably room for further improvement. However, we don't currently have a work group tasked with reviewing and updating the GS1 Web vocabulary, so currently any updates need to be triggered as formal work requests (submitted via https://wr.gs1.org/ then reviewed by the GS1 Global Master Data Standards Maintenance Group) - and are done on a piecemeal basis. Not ideal but that's where we are currently. I don't have any authority to unilaterally change things in the GS1 Web vocabulary - nor do I have direct access to the GS1 webserver. If you and others feel strongly that there are significant improvements to be made, then please discuss with @philarcher about whether a mission-specific work group should be reconvened within GS1 to discuss those potential updates. Alternatively, you're very welcome to propose a modified version of the Turtle / JSON-LD file, which Phil and I can then review and use as the basis for submitting a work request for those updates - though we will probably need to find some end-user companies who are willing to support the change (which means that they need to understand why the proposed changes are a good thing to do). At present, my main priorities for GS1 are EPCIS/CBV 2.0, TDS/TDT 2.0 and updates to the GS1 Digital Link toolkit. Phil and I handle the technical updates for the GS1 Web vocabulary but only when formally requested by a work group and approved by the GMD SMG. |
|
As I think more about it... Having properties like: An alternative representation: Where So I think I am saying that gs1:functionalName and gs1:regulatedProductName aren't |
|
Another example of lack of universal props: I can express GDTI in schema (though a bit inelegantly), but not in GS1. <https://id.gs1.org/253/09535600000290000234> a gs1:CertificationDetails;
schema:identifier
[a schema:PropertyValue; schema:propertyID "GDTI"; schema:value "09535600000290000234"];
gs1:certificationIdentification "2-234";
gs1:certificationAgencyURL <$PGLN_COMPANY3>;
gs1:certificationStandard "EU Energy Efficiency, Directive 2017/1369";
gs1:certificationType <https://example.org/resource/certs/EU-energy-efficiency>;
gs1:certificationValue "A"; # also see https://schema.org/EnergyEfficiencyEnumeration
gs1:certificationSubject <$GTIN_PRODUCT1>;
gs1:certificationAuditDate "2020-11-20"^^xsd:date
gs1:certificationStartDate "2020-11-23"^^xsd:date;
rdfs:comment "Use Content Negotiation to get RDF, PDF, HTML";
gs1:certificationURI <https://id.gs1.org/253/09535600000290000234>. # self-link(Explanations):
|
|
Hi @justin2004 The GS1 Web vocabulary also supports categories for products / trade items via the following properties: https://www.gs1.org/voc/gpcCategoryCode https://www.gs1.org/voc/additionalProductClassification which points to a class So I agree with you that structured category / classification codes (such as UNSPSC and GS1's Global Product Classification (GPC) [ https://www.gs1.org/standards/gpc and https://gpc-browser.gs1.org/ ] ) are a better approach, the GS1 Web vocabulary also supports gs1:functionalName expecting a language-tagged string value. In a similar way, the GS1 Web vocabulary supports a https://www.gs1.org/voc/ingredientStatement but also something more structured, via https://www.gs1.org/voc/FoodBeverageTobaccoIngredientDetails |
|
GS1 Digital Link URIs can be configured to redirect to any kind of Web resource of any Media Type, so redirecting to a PDF certificate is perfectly OK - and you can use the https://www.gs1.org/voc/certificationInfo link type to specify that link. |
|
There's been a lot of discussion here and, as ever, Mark has provided his insights. For background, Mark worked on the original WebVoc which was several years before I showed up here. I have found that whenever I try and apply purist Linked Data approaches (like always using existing terms and URIs where possible) Mark has a solid reason for why it's not right in this circumstance. Typically this comes from the fact of the voc's genesis as an RDF expression of the underlying GSDN/GDD data model - which I accept can be frustrating. The other issue is less controversial: the semantics of schema.org are, shall we say, imprecise? And sometimes we need/want to encourage precision. On the specific point raised about extending the DL URI with more path elements or using a fragment: as I think everyone here recognises, adding sth like /address to the end of a DL URI is not wrong since you're essentially minting a new URI that is never intended to use used as an item identifier. However, for the reasons Mark states, using fragment IDs would be less likely to trigger confusion and errors we can avoid. Hmmm... this is an old problem. A wiki page at https://www.w3.org/wiki/HashVsSlash might be instructive here. If the address data is typically in the same resource then using the hash is preferred. If the address really is a separate resource, then / is preferred. @mgh128 is correct - the DL spec remains silent on the issue. On the domain of gs1:linkType - we relaxed that completely when we added the new link types that came from the work on GLN modernization. The ratified version of the Web Voc now, deliberately, has no domains for link types. The gs1:AI data type is there for our AIs so it's for triples like We could have a generic top level class of 'identified item' but I'm not sure that would really be an advance on just using owl:Thing?? Separately, the Web Voc is now getting more attention, and is being seen as more of an integral part of the GS1 system, that ever. It's managed, formally, by the GMD SMG which takes into account the full range of GS1 vocabulary terms which I'm comfortable with. A new WG just to update the WebVoc might be warranted - but I fear it might also be frustrating because of the need to align with other bits of GS1 where Sem Web and LD are not part of the thinking process. I don't have a definite answer on this one. As ever, it's about community interest and available resources. |
Hi @philarcher and @mgh128 , we're working on LD examples for GS1 Forum 2022-02 and have some questions:
gs1:props and I should useschema:, right?^^gs1:AI?(254)is the AI for "SGLN extension" but using it together with the two IDs in the same string doesn't seem right?#instead of/for this casE?Cheers!
The text was updated successfully, but these errors were encountered: