Template talk:Concept

Properties

rdfs:range

Include rdfs:range? It can be set for now only for group administrator, i.e. hidden for normal user in forms. --Andreas Plank 17:22, 29 August 2012 (CEST)

rdf:type

Do we need a parameter for rdf:type? --Andreas Plank 16:50, 11 September 2012 (CEST)

imported from / is defined by

{{concept
…
|imported from      = property: imported from         → doesn't it replaces rdfs:isDefinedBy ?
|is defined by      = property: rdfs:isDefinedBy
…
}}

The use cases probably overlap? imported from is a semantic-mediawiki-property designed to put a page from the Wiki (definitely a "property:", probably but untested, also classes=categories) into another namespace, i.e. the RDF exports with namespace/URI. Question: Is the use of imported from always identical to is defined by? Note: on a property page we would need “imported from” but set once there it does not need to be set again elsewhere. At present both fields are in the template and forms, but it would be nice to simplify this. --Andreas Plank 10:39, 6 September 2012 (CEST)

Agree, it sounds like a very good solution to reuse the "imported from" property as the value for rdfs:isDefinedBy --Dag Endresen 14:45, 10 September 2012 (CEST)

I realize now: anyway this feature “imported from” must be available when placing template concept on a property or category page, but it is an either “imported from” or rdfs:isDefinedBy, not both at the same time. --Andreas Plank 16:50, 11 September 2012 (CEST)

We would like to see rdfs:isDefinedBy in the exported RDF. Does using the imported from wiki functionality automatically provide this for us? Question: imported from is of the form [ns prefix]:[concept name], while the rdfs:isDefinedBy is the URI for the resource where the concept is defined (not necessarily including the term name?). RDFS definition: "rdfs:isDefinedBy is an instance of rdf:Property that is used to indicate a resource defining the subject resource". (Note: rdfs:isDefinedBy is a subclass of rdfs:seeAlso) --Dag Endresen 10:16, 12 September 2012 (CEST)

Default automatic categories

What default categories should we set for pages using the Concept template?

• Always "Category:skos:Concept". Or "Category:Concept"?
  • Notes: concept scheme and concept collection templates will set “Category:skos:Collection” an “Category:skos:ConceptScheme” etc.

    Question: "category: skos:ConceptScheme" / "category:skos:Collection" or “category: Concept scheme” / “category: Concept”? --Andreas Plank 18:12, 7 September 2012 (CEST)

• If "imported from:" is set for a concept, then set a "Category:imported concept" (old version used"Category:imported term")?
• Should for the values in concept scheme: automatic categories be set? Example: "Category:DarwinCore".
• Should for the values in concept collection: automatic categories be set? Example: "Category:Audubon Core Managment Vocabulary".
• is it correct to define [[Has default form::…]] on category: skos:Concept ?

It is not strictly necessary to set a category for each of these, since the properties can be queried in ask-queries and we can add filters also on Special:BrowseData.

--Andreas Plank 11:35, 6 September 2012 (CEST)

I believe we discussed that a term/concept reused in multiple skos:ConceptScheme (concept vocabularies) would be declared only once by one single Wiki page. When the skos:ConceptScheme is a single-value option in the Concept template edit form, each concept can only be in one single ConceptScheme? E.g. dcterms:accessRights is declared as in DublinCore, while this Concept should be included in both DublinCore and in DarwinCore...? There is a difference in the meaning between rdfs:isDefinedBy and skos:inScheme (I will look for the SKOS documentation page where I read about this difference). --Dag Endresen 15:30, 10 September 2012 (CEST)

“When the skos:ConceptScheme is a single-value option in the Concept template edit form, each concept can only be in one single ConceptScheme?”
Well, technically this can be changed to store multiple values in one template parameter, e.g. value separation by semicolon ;
So I guess we need multiple values anyway for parameter "concept collection" and "concept scheme"? --Andreas Plank 10:44, 11 September 2012 (CEST)

I believe that for skos:inScheme semicolon separated values would work fine. --Dag Endresen 12:33, 11 September 2012 (CEST)

Multiple values for concept collection could also work - however: For the concept collection there is no skos:inCollection (no SKOS concept where a description of a concept can declare that the concept is in a concept collection). SKOS only have skos:member where the description of the concept collection can list the concepts that are organized to the respective collection. So perhaps we on the wiki page for the respective concept collection should rather have a button to add members...? Perhaps this twist would also even be more user-friendly and possibly leaving less confusion to what is the difference of a ConceptScheme and a concept Collection. --Dag Endresen 12:33, 11 September 2012 (CEST)

Personally I would find it more confusing to have reverse ways of defining the membership in a schema and collection. I think it should remain on the concept page, which is the most-used edit form. I agree that the collection field on concept pages needs to be multivalued. --Gregor Hagedorn 22:57, 11 September 2012 (CEST)

Would we also need a button Add or edit a concept collection next to the Add or edit a concept button on the concept vocabulary (ConceptScheme) page? --Dag Endresen 12:36, 11 September 2012 (CEST)

I agree --Gregor Hagedorn 22:57, 11 September 2012 (CEST)

Alistair Miles wrote on 6 Nov 2007 about the difference between rdfs:isDefinedBy and skos:ConceptScheme, http://lists.w3.org/Archives/Public/public-swd-wg/2007Nov/0011.html, and http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptSchemes/DiscussionPiece Here Alistair Miles discusses whether a property pointing to skos:Concept can be in only one skos:ConceptScheme, or if it can be included in more than one. --Dag Endresen 16:56, 10 September 2012 (CEST)

Both Darwin Core and Audubon Core actually include terms/concepts from other concept vocabularies such as Dublin Core. It seems like Darwin Core and Audubon Core imports only some Dublin Core terms/concepts and not "all" of Dublin Core... How do we express this? I believe as mentioned that skos:Collection is only intended as an organizing or grouping principle within a skos:ConceptScheme and would therefore not be suitable to express this, or...? --Dag Endresen 16:56, 10 September 2012 (CEST)

I agree that it should be possible that a concept is a member in more than one scheme. I originally thought Collection is more suitable for that, but I now agree that it is necessary and by design in the skos model that equivalent concepts, having the same uri, are members in different schemes. --Gregor Hagedorn 21:15, 11 September 2012 (CEST)

Obviously this means that both the scheme and collections properties, from the viewpoint of a skos:concept object, must be multivalued. Practically there is the question of how? The most elegant solution in my mind would be to simply treat them as relations, similar to narrower and broader. Would this be adequate? --Gregor Hagedorn 21:15, 11 September 2012 (CEST)

Treating both scheme and collection as relations from the Concept edit form/page sounds very fine. In my mind I like to think of the term wiki as a strong focus on the concept/terms. I would like to believe that the organization of the concept/term into ConceptScheme are more important for governance practices and less important for reusing the declared concept/terms in applications. --Dag Endresen 10:03, 12 September 2012 (CEST)

Using vann:termGroup and not skos:member to organize concepts into concept collections is all fine with me. I believe that using XSLT or similar to infer the skos:member might still be useful for the "final" RDF document... --Dag Endresen 10:03, 12 September 2012 (CEST)

Translations

Experiments how it can best be set correctly (no feedback necessary at the moment, see also Testpage internal objects and Testpage subobjects):

1. #subobject is more appropriate, because it creates a hash id on a page, that has to be set manually, e.g. page#en or the following proposal, e.g. “page#propertyName@en”. #set_internal uses only integer hash ids.
   • what should export in RDF? Proposal: a syntax like "propertyName@ISO-lang-code" as a subproperty of propertyName?
   • technical note: in a wiki page “#propertyName@en” will always be ancorencoded: {{anchorencode: propertyName@en}} returns “propertyName.40en” (that is {{urlencode: propertyName@en}} and replace “%” by “.”) --Andreas Plank 12:12, 6 September 2012 (CEST)

   Problem with this approach is that the data value does not appear in the RDF export

2. Alternative: use type record:
   

   Property:skos:definition-translated ← [[Has fields::skos:definition; dc:language]]

   • An advantage over #subobject is that the data appear in the RDF as nested elements
   • Problem is the separator ; (semicolon). It is likely that a definition or a note has a ; in it.
   • Problem is may be also the naming of this Property that one understands it intuitively. Is the suffix “-translation” concisely? --Andreas Plank 12:56, 27 September 2012 (CEST)
3. Alternative: use for each language a single property like propertyName@en, propertyName@fr etc. and define it as subproperty of "propertyName" --Andreas Plank 16:08, 10 October 2012 (CEST)

   for e.g. Property:propertyName@en in RDF appears then only a <rdfs:subPropertyOf rdf:resource="http://terms.gbif.org/wiki/Special:URIResolver/Property-3ApropertyName"/>. This might get resolved. --Andreas Plank 09:55, 12 October 2012 (CEST)

4. Alternative (Gregor’s proposal): save values for SMW as "en:definition text-as-property-value", "de:deutsche-Definition-als-Attribut-Wert" etc. (is now [2012-10-12] used) --Andreas Plank 10:28, 12 October 2012 (CEST)

Correct relation of concept collection its concept scheme

If we have 2 concept collections in 2 concept schemes that originally use the same label, e.g. “Record-level Terms” (see archived dcterms:accessRights) then how can we extract the correct relation? Maybe this must be implemented technically in form: Concept? --Andreas Plank 10:47, 26 September 2012 (CEST)

In SKOS a concept collection cannot belong to two schemes. If the label is identical then it is best practice is to prefix the original concept collection label with the name of the scheme. --Andreas Plank 10:36, 15 October 2012 (CEST)