Which Tag Vocab to use?

[melvincarvalho]

Which Tag Vocab to use?

Tag vocabulary for tagging things. When you tag,. do it in a way that people in your project share the meaning of the tag.

Which tag vocab to use? I also would like something for bookmarks.

Here is a Search using LOV: https://lov.linkeddata.es/dataset/lov/terms?q=tag

Some vocabs are down

Commontag

Unfortunately commontag has been down for a while

http://commontag.org/ns#

BBC

BBC tag is down

https://www.bbc.co.uk/ontologies/tagging#terms_TagConcept

Cinelab

Cinelab is down

https://essepuntato.it/lode/owlapi/http://advene.org/ns/cinelab/ld

Tag Ontology

Tag ontology is down

http://www.holygoat.co.uk/owl/redwood/0.1/tags/tag

Possible solutions

I found commontag a bit complex. Ideal for my needs would be something like

<URI> :tag """tag""" .

There was a suggestion from around sioc topic and sioct Tag

Currently, I'm using urn:string:tag as a placeholder until there is a consensus.

So hopefully we can work out what to use

[RubenVerborgh]

I like sioc:Topic.

PS Deleted comment above was an autoreply.

[melvincarvalho]

After some discussion on gitter the following predicate was suggested:

https://schema.org/keywords

[RubenVerborgh]

But those seem to have literals as range, so non-localizable?

[csarven]

What's the intention? Terms from taxonomies or free form? A bit of both?

Not http: but... the tag: URI scheme ( https://tools.ietf.org/html/rfc4151 ) can be used to create tags and has the advantages (and baggage?) that you'd gather. Some interesting use like content warnings, private tags.

I'd suggest schema:about (and refer to generally persistent URIs.. wikidata/dbpedia/dictionaries etc..) over schema:keywords.

[melvincarvalho]

@csarven thanks much for reminding me of the tag: scheme. It occurred to me, I've been looking for a solution to this for about 5 years!

   Examples of tag URIs are:

     tag:timothy@hpl.hp.com,2001:web/externalHome
     tag:sandro@w3.org,2004-05:Sandro
     tag:my-ids.com,2001-09-15:TimKindberg:presentations:UBath2004-05-19
     tag:blogger.com,1999:blog-555
     tag:yaml.org,2002:int

The examples at first blush dont seem a great fit. But I may be missing something.

My particular use-case is related to tagging a URI ie a bookmark. "This bookmark is about JavaScript", "This bookmark is about Minecraft" etc. Or like a microblogging #HashTag

One criticism of schema: keywords was that they are designed to be comma-separated

Reading https://schema.org/about didn't seem related to tagging as described.

[kjetilk]

Personally, I'd revive the commonTag... I prefer dereferenceable HTTP URIs for tags, as one really nice thing to do is to map your tags to other tags, so that their meaning can be inferred in some cases.

Not a terribly easy choice, I admit, given all the time that has gone by, so all very IMHO, but I think commonTag had the right idea.

[melvincarvalho]

Personally, I'd revive the commonTag

@kjetilk how would that work with the commontag website down?

I prefer dereferenceable HTTP URIs for tags

prefer to what ie what's an alternative?

one really nice thing to do is to map your tags to other tags, so that their meaning can be inferred in some cases

hmm Im not easily able to visualize this. Have you used this technique in the past, or do you have a user story

[csarven]

I don't find schema:keywords particularly useful (or even convenient) beyond a write-once for a human-readable case. Depending on an application's point of view, it is rather clumsy to update..

schema:about is just about categorisation in the general sense. dcterms:subject would be equally fine and useful in my opinion.

Generally dereferenceable http URI would be ideal or preferable to literals. But, it still comes back to whether what's intended is more in the direction of a controlled term or free form. As you know, http URI would still make it possible to have a human-readable label that's not controlled.

Melvin, I acknowledge that you are not in favour of AS2 but I'll mention it any way for the purpose of documentation in case of use to anyone else: there is as:tag ( https://www.w3.org/TR/activitystreams-vocabulary/#dfn-tag ) which is perhaps as close as it gets to probably what you're after.

There is also the Web Annotation motivation oa:tagging ( https://www.w3.org/TR/annotation-vocab/#tagging ). FWIW, dokieli uses oa:tagging as the purpose of an annotation body with oa:bookmarking motivation ( https://www.w3.org/TR/annotation-vocab/#bookmarking ) eg. https://linkedresearch.org/annotation/csarven.ca/%23i/217cbc62-e52a-43ef-90fb-429f4846713e . I think this works great to capture bookmarking and tagging activities with a lot of flexibility and extensibility. For instance, allow the user to enter free text for their use and optionally interlink to known terms (URIs) or maybe even offer to suggest their entry with a term.

So, a lot of options.

[kjetilk]

Personally, I'd revive the commonTag

@kjetilk how would that work with the commontag website down?

I suppose that we could buy the domain.... But sssh, the price might be high if interest for it is registered...

I prefer dereferenceable HTTP URIs for tags

prefer to what ie what's an alternative?

Prefer http to tag URI scheme.

one really nice thing to do is to map your tags to other tags, so that their meaning can be inferred in some cases

hmm Im not easily able to visualize this. Have you used this technique in the past, or do you have a user story

Yeah, I implemented this for my.opera.com back in 2006 or 2007. I wrote an UI that people could use to map their tags to WordNet, which was the big structure of the day. It saw some use, but rather few used the overall RDF system in my.opera.com.

What makes tags interesting are both their strengths and weakness: You don't need to have any kind of agreement around the meaning of a tag, you just make your own tag cloud, which is great, because that allows people to create a very lightweight classification, but it is also a problem, because you can't really derive much interop from it.

So, finding a property that links resource and tag is nice, and I don't have a strong opinion on that, but I would like to have something more, and that something more was pretty well formulated in commonTag.

[melvincarvalho]

I suppose that we could buy the domain.... But sssh, the price might be high if interest for it is registered...

Seems a bit like wishful thinking. Would you be willing to take on this task?

Prefer http to tag URI scheme.

But what about a string literal? You've not mentioned how you could link a URI to a string.

[kjetilk]

Prefer http to tag URI scheme.

But what about a string literal? You've not mentioned how you could link a URI to a string.

commonTag had that.

[melvincarvalho]

commonTag had that.

@kjetilk Hmmm there seems to be some conflation here

Perhaps it would be helpful to consider this from the perspective of an RDBMS

Let's say I have a Bookmark table, which has URI, name, creator etc. I also want to add a tag to that bookmark. Let's leave aside that RDF is a set and you have multiple tags.

The two design decisions are whether whether to add a tag column to the table. ie the easier way, and the question posed originally would be what to name it. That's the question looking for an answer.

There is the other design approach would be to make a new table and use the tag as a foreign key. Obviously this is a more complex approach with more overheads but has extensibility benefits. That is the second conversation and we've not got a practical answer there too, because your preferred choice would be require buying a domain restarting a whole project. This might take weeks, or might never happen. What is the solution that we can use today?

[kjetilk]

OK, it sounded like your requirement was to share meaning. If you just want to use a literal, then schema:keywords is a good choice. My experience from way back was that it doesn't help knowledge organization, and I tend to want to use tags for that, in which a more complex design is required.

It doesn't necessarily mean that we need to revive the old domain, but something quite similar is needed.

[melvincarvalho]

Thanks. Interesting discussion.

I'm going to briefly touch on what I think is the general case of this problem, but it should probably move to another venue or issue for discussion. I'll write it out here because I think it's a way to solve this problem and others of its kind.

Do we need blank predicates?

In RDF a blank node is a node without a name. A debate has existed, "Do we need blank nodes?". Generally, the answer most give is yes. Let's think about why that is. Well, one reason is that a node can exist without having a name. Why? Because it hasn't been named yet. If you think about it make sense. Because we observe things, then give them a name, normally.

In the same way, predicates describe relationships between two things. In the real world two things can have a relationship but not a name (aka it's complicated!). Very often the problem you have as a developer is that you know the subject and object, but you are unable to name the predicate, so we end up inevitably every so often with discussions of this kind.

So, do we need blank predicates? The answer I think is No. But do we need something like it, so that we can continue to work without having to take time out to find a predicate or a name.

Let me note this problem does not exist in JSON. Or indeed, other languages with variables. I would just write 'var tag' and I am done.

What would be helpful for me, and maybe for others, would be a place holder so that we can work without having fully named a relationship. Just like you can work without naming a node. I know of no way to solve this general case in RDF, but it might be a useful discussion. This is why I sometimes use urn:string:tag for this purpose, but it has never caught on, and is sometimes frowned upon.

In any case. Thanks for the feedback. I still am unsure what predicate to finally use, but I'm closer to a solution, thanks. And indeed I don't want to derail this discussion with my use case. After all the use case is for the project pane, so let's find out what's needed there, or try to imagine it. So will track responses here.

Happy to discuss further, maybe on another issue, but don't want to veer off-topic. Cheers!